Jak ważne są wzorce projektowe w programowaniu?

Jestem studentem uniwersytetu i właśnie zacząłem uczyć się o wzorach projektowych i staram się zrozumieć ich cel. Próbowałem je badać, ale wszystkie zasoby, które znalazłem, wydają się mówić o nich w sposób akademicki, a nie profesjonalny.

Jaki jest ich cel i czy należy się ich uczyć?

Wzory projektowe świetnie nadają się do szybkiego komunikowania swoich zamiarów - każdy wie, czym jest Fabryka.

Naprawdę, naprawdę, bardzo złą rzeczą jest rozpoczęcie dopasowywania kodu do wzorców lub rozdzielanie obowiązków według wzorców lub czegoś podobnego. Jedną rzeczą jest powiedzieć „Ten obiekt jest Fabryką”, a drugą powiedzieć „Ten obiekt powinien być wyłącznie Fabryką”.

Z artykułu w Wikipedii na temat Wzorów projektowych :

Przydatność mówienia o wzorach polega na wspólnej terminologii do omawiania sytuacji, które projektanci widzą w kółko.

Od bardzo dawna mamy poważny problem z inżynierią oprogramowania: zatrudniasz nowoprzybyłego do projektu i bez względu na to, jak dobrze znają język programowania, miesiące zajmują mu zapoznanie się z tym, jak to się dzieje w twoim projektu, zanim będą mogły być produktywne. W inżynierii sprzętowej rozwiązali ten problem bardzo dawno temu: mają wspólną terminologię zwaną „schematami”. Zatrudniasz inżyniera sprzętu, rano podajesz schematy swojego projektu sprzętowego, pozwól im się go przestudiować, a wieczorem, zanim nadejdzie czas, aby zadzwonić do niego w dzień, mogą podnieść pistolet lutowniczy i stać się produktywnym. Staraliśmy się znaleźć sposoby, aby być w tym lepszym; standaryzacja języków programowania była jednym ze sposobów; biblioteki standardowe (obecnie biblioteki klas) były innym sposobem; ale jednym z najważniejszych sposobów może być wzorce projektowe. Czy są one ważne? Obstawiasz!

Istnieją naprawdę dwa różne, istotne powody istnienia wzorów.

Pierwszy został już dość dobrze wyjaśniony: użycie wzorców smaruje komunikację między programistami. Jeśli oboje rozumiemy, że kiedy mówię „Obserwator”, mówię o bardzo specyficznej strukturze kodu, to mogę bardzo szybko opisać, jak działa kawałek kodu, który używa tego wzorca. Alternatywą jest pełne opisanie rozwiązania, które jest czasochłonne i podatne na błędy. („Cóż, stworzyłem tę czystą klasę wirtualną, która opisuje i interfejs dla obiektów konsumenckich, a następnie stworzyłem klasę, która utrzymuje listę aktywnych konsumentów, która ...”)

Drugą zaletą wzorców jest to, że są one gotowymi formami rozwiązań typowych problemów. Jeśli znasz swoje wzorce i na przykład napotkasz problem, w którym musisz znaleźć dobry sposób na uzyskanie informacji od (prawdopodobnie wielu) obiektów producenta do wielu obiektów konsumpcyjnych, bez wprowadzania niepotrzebnego łączenia między klasami, rozpoznasz „to to praca dla obserwatora! ” i od razu będziesz wiedział, jak rozwiązać problem.

Korzyści te również naprawdę się wzmacniają. Pozwalają one szybko rozwiązać niektóre typowe klasy problemów, a po zakończeniu można bardzo szybko komunikować, w jaki sposób rozwiązano problem.

Porównaj to ze światem, w którym wzory „nie istnieją”. Wpadasz na jedną z tych klas problemów, które na ogół nie są trywialnymi problemami projektowymi, i spędzasz sporo czasu na wymyślaniu dobrego rozwiązania (które, nawiasem mówiąc, bardzo prawdopodobnie będzie wyglądać podobnie do odpowiedniego wzorca). Następnie pojawia się twój współpracownik i chce wiedzieć, jak go rozwiązać, i spędzasz godzinę na omawianiu tego, jak i dlaczego.

Wszystko to wiąże się z zastrzeżeniem, które powinno wydawać się dość oczywiste: nie próbuj wrzucać problemów we wzorce, które nie pasują. Jeśli wzorzec nie pasuje do problemu, rozwiązanie skończy się zawiłością i utracisz korzyści wynikające ze zmniejszenia nakładów wynikające z wzorców. Dodatkowo, ponieważ twoja praca nie będzie już pasować do zrozumienia przez współpracowników znaczenia wzoru, stracisz koszty korzyści komunikacyjnych. W rzeczywistości prawdopodobnie zwiększysz koszt komunikacji ponad koszt braku wzorców, ponieważ niewłaściwe użycie tego schematu da twojemu współpracownikowi fałszywe zrozumienie rozwiązania, co jest gorsze niż brak zrozumienia.

Wzorce dotyczą ponownego wykorzystywania pomysłów i koncepcji oraz ustanowienia wspólnej / spójnej platformy do ich przekazywania.

Wszyscy jesteśmy zgodni (!), Że teoretycznie ponowne użycie kodu jest dobrą rzeczą - ale okazuje się trudniejsze niż chcielibyśmy to robić praktycznie (pod pewnymi względami to się zmienia, ale zawsze będzie wyzwaniem ). Ale w rzeczywistości wiele z tego, co chcemy ponownie wykorzystać, to sposób robienia rzeczy, użycie pewnego rodzaju szablonu do skonstruowania rozwiązania konkretnego problemu - są to Wzory. Tak więc dochodzimy do przypadku, w którym mówisz, że dobrym podejściem do rozwiązania problemu X jest użycie Wzoru Y i wiemy, że elementy wzoru Y to a, b i c, i ruszamy. Ponieważ wzory są szeroko rozumiane, nie musisz szczegółowo wyjaśniać, jakie są korzyści z komunikacji.

Zabawne w wzorcach jest to, że języki i frameworki ewoluują, aby zapewnić lepszą obsługę wspólnych wzorców, a efektem netto jest to, że otrzymujemy coraz więcej i lepsze ponowne wykorzystanie kodu (coraz więcej klocków Lego!), Ponieważ sposób, w jaki budujemy aplikacje (poprzez wdrażanie wzorców ) ułatwia ponowne użycie.

Wzory projektowe są po prostu znanymi cegłami, na których opiera się każde oprogramowanie. Są ważne z następujących powodów:

1. Są niezależni od języka. Gdy już wiesz, jaki wzorzec projektowy jest odpowiedni dla danego problemu / architektury / zadania, możesz go wdrożyć w dowolnym języku wieloparadygmatycznym - niech to będzie C #, Java lub Python - rozwiązanie będzie w większości przypadków takie samo, po prostu masz dostosować składnię. Oznacza to, że możesz przenieść swoje doświadczenie z programowania w jednym języku na inne języki, o ile pozostajesz w tej samej domenie problemowej (a może nawet w różnych domenach).

2. Pomimo faktu, że wzorce projektowe wiążą się z paradygmatem programowania , co oznacza, że ​​wzorce projektowe do programowania obiektowego (najsłynniejsze, znane również jako wzorce „Gang of Four” ). Wzory pozwalają zrozumieć, do czego najlepszy jest ten paradygmat, i pomóc wyjść poza samą składnię.Na przykład widziałem wiele implementacji w języku C # i Javie, gdzie ludzie po prostu zaprogramowali sposób, w jaki to zrobili w Basicu lub Fortranie - mają doskonały imperatyw do rozwiązywania problemów i używają OOP tylko do renderowania tego rozwiązania - bez dziedziczenia , brak polimorfizmu, wszystkie metody są publiczne itp. Wzory projektowe pomagają spojrzeć za te koncepcje i zobaczyć, jak działają w prawdziwym życiu. To samo dotyczy wzorca projektowego w innych paradygmatach, takich jak programowanie funkcjonalne.

3. Wzory są na ogół przydatnym sposobem przedstawiania pomysłów i pochodzą z informatyki z architektury. Kiedy zrozumiesz ideę pewnego „wzorca”, możesz łatwo rozpoznać ten wzorzec w innym problemie i rozwiązać go za pomocą tego wzorca (prawdopodobnie nieco zmodyfikowanego, aby lepiej rozwiązać Twój problem). Istnieje mnóstwo różnych wzorców: w integracji oprogramowania dla przedsiębiorstw , w testowaniu kodu źródłowego itp. Po prostu szukaj wzorców w książkach z informatyki.

4. Oprócz nabywania dobrych praktyk poprzez uczenie się wzorców , możesz łatwo nauczyć się, jak unikać głupich błędów w kodzie, badając anty-wzorce . Istnieje wiele książek zawierających typowe błędy w różnych domenach w postaci anty-wzorów, które są bardzo zabawne i jednocześnie edukacyjne. Nawiasem mówiąc, uwielbiam nazwy tych anty-wzorów!

Wzorzec można uznać za sprawdzony sposób rozwiązania problemu zrozumiałego przez Ciebie i innych programistów. Np. Problem polega na utworzeniu posortowanej listy danych, a następnie możesz użyć połączonej listy lub umieścić dane w wektorze i posortować. Prawdopodobnie znasz obie te opcje, ponieważ możesz już znać wzorzec połączonej listy lub wzorzec ładowania i sortowania wektorów. Możesz znać zalety i wady każdego z nich i nie musisz widzieć implementacji, aby zrozumieć, co się dzieje.

Myślę, że zaczynasz programować, nie sugeruję, abyś wcześnie nauczył się projektowania. Nauka i zrozumienie wzorca projektowego musi opierać się na doświadczeniach związanych z tworzeniem oprogramowania. Powinieneś więcej ćwiczyć kodowanie i znaleźć, który styl kodu jest zły, a następnie nauczyć się wzorca projektowego, aby poprawić projekt.

Przydatność wzorca projektowego zależy od wybranego języka. Im mocniejszy język wybierzesz, tym mniej będziesz musiał zrozumieć i wdrożyć wzorce projektowe. Wzorzec projektowy może być sygnałem, że Twój język jest do bani, brakuje wbudowanej funkcji.

Joe Gregorio wygłosił świetną rozmowę o braku wzorców projektowych w Pythonie

Wzorce projektowe są rozwiązaniem typowych problemów napotkanych podczas tworzenia oprogramowania. Zawsze istnieje więcej niż jedno rozwiązanie niektórych problemów, a wzorce projektowe pomagają zdecydować, które rozwiązanie jest najlepsze, zapewniając zestaw dobrych rozwiązań tych typowych problemów.