Czy wzorce projektowe są generalnie siłą na dobre czy złe? [Zamknięte]

Słyszałem, jak argumentowano, że wzory są najlepsze od krojonego chleba. Słyszałem także, jak argumentuje, że wzorce projektowe mają tendencję do zaostrzania „syndromu drugiego systemu”, że są one w znacznym stopniu nadużywane i że ich użytkownicy uważają, że są lepszymi projektantami niż są w rzeczywistości.

Mam tendencję do zbliżania się do byłego obozu, ale ostatnio widziałem projekty, w których prawie każda interakcja jest zastępowana relacją obserwatora, a wszystko jest singlem.

Biorąc pod uwagę korzyści i problemy, czy wzorce projektowe są ogólnie dobre czy złe, i dlaczego?

Wzory projektowe są językiem , a nie poradą do pisania programu lub umowy. Ich głównym zastosowaniem jest wyjaśnienie a posteriori, w jaki sposób komponent lub system został (lub będzie) zaimplementowany. Zamiast wchodzić w zbyt wiele szczegółów, możesz po prostu powiedzieć kilka słów, które mogą opisać implementację wystarczająco dobrze, aby słuchacz zrozumiał, jak to działa i co było w tym ważne.

Alex: Hej, jak tworzone są pliki konfiguracyjne?

Bob: Są generowane przez fabrykę, w której rezyduje config.h.

Teraz Alex wie, że tworzenie plików konfiguracyjnych wymaga niebanalnych przygotowań, ponieważ w przeciwnym razie ich tworzenie nie byłoby zamknięte w fabryce.

Jednak jeśli Bob był fałszywym wzorcem i po prostu używał wzorców tu i tam, Alex nie mógł powiedzieć nic o tworzeniu konfiguracji, ponieważ Bob wszędzie używał fabryki. Doprowadziłoby to również do nadmiernej złożoności programu.

Najpierw zaprogramuj, a następnie wykryj wzorce w kodzie, a nie odwrotnie. Tak są skutecznie wykorzystywane.

Wzory projektowe są świetne . Prawidłowo używane sprawiają, że kod jest łatwiejszy w utrzymaniu, łatwiejszy do odczytania i pracy z nim. Częścią bycia dobrym programistą jest wiedza, kiedy przestać i zobaczyć, że jakiekolwiek dalsze refaktoryzowanie przeważy korzyści. Korzystanie z samych wzorców projektowych nie czyni kogoś dobrym programistą, ale wiedza o tym, kiedy i gdzie ich użyć. Podobnie jak w przypadku innych rzeczy na tym świecie, wzorce projektowe mogą być ekstremalne i nadużywane. Wiem, że wciąż szukam (i długo będę) idealnej równowagi w moim kodzie, w której każdy wzór ma swój cel i układa się idealnie, jak kawałek układanki.

Wzory projektowe są świetne, jeśli są właściwie stosowane.

Warto pamiętać, że idea wzorców projektowych wywodzi się z architektury. Architektura może się bardzo różnić. Istnieje jednak wiele podstawowych pomysłów obecnych w każdym budynku. W ten sposób pomyśl o wzorach jako elementach konstrukcyjnych. Należy zauważyć, że nie każdy budynek zawiera wszystkie możliwe wzory architektoniczne.

Powiedz, że projektujesz dom. Zamiast otwierać drzwi wejściowe na ulicę, chcesz wejść do chronionego obszaru przed wejściem do domu, czyli przedpokoju. Ten obszar będzie pasował do określonego wzoru. Mianowicie będzie miał dwa wejścia, niektóre ściany i prawdopodobnie dach. Uwaga: wzór nie określa drzwi, okien ani liczby ścian. W większości wdrożeń będą dwoje drzwi, cztery ściany i może okna. Jednak wzór opisuje zamknięty obszar z dwoma wejściami. Jeden prowadzi do samego przedpokoju z zewnątrz domu, a drugi do reszty domu. Kluczem tutaj jest to, że jeśli chcesz przedpokoju, musisz zamknąć obszar i zapewnić dwa wejścia do tego obszaru.

Typowe problemy ze wzorami projektowymi w programowaniu są nadmiernie użytkowane i przekonanie, że są srebrnymi kulami, aby rozwiązać każdy problem. Oni nie są. Są to sposoby komunikowania się i myślenia o przydatnych pomysłach programistycznych. Jeśli fragmentami składni określonego języka są cegły i zaprawa, wzory opisują przydatne sposoby uporządkowania ich w celu spełnienia określonych potrzeb.

Uważam, że wzornictwo jest bardziej „ radą ” niż niezmienną umową, której absolutnie należy przestrzegać. Czemu? Właśnie z tego powodu, o którym wspomniałeś. Podążanie za wzorcem projektowym we wszystkim prowadzi do dużego bałaganu kodu, który nie pozwala na zastosowanie wzorca w pierwszej kolejności.

Dlatego nienawidzę witryn takich jak Java Practices . Pewnie niektóre z pomysłów są dobre, ale potem autor postanowił napisać cały program (plus framework) zgodnie z każdym wzorzec projektowania, o którym wspominał. Autor napisał również każdy artykuł z dużymi przerażającymi cytatami, które sprawiają, że czytelnik uważa, że ​​faktyczne praktyki java są okropne i należy ich unikać jak zarazy.

TL; DR: Użyj wzorów. Tylko ich nie wykorzystuj

Zobacz także ten wątek na SO. Kolejne wzorce projektowe POV są kodami wzorcowymi, aby zrekompensować wady zastosowanej metodologii. Nie jestem fanem zbytniego świętowania tych obejść.

Wolę te w środku. Jak słusznie zauważył plakat, zrozumienie wzorów nie czyni cię dobrym programistą. Z drugiej strony zrozumienie wzorca pomoże ci zostać dobrym programistą.

Zrozumienie związku wzorców i zobaczenie wzoru w projekcie (na etapie koncepcji) sprawi, że będziesz dobrym programistą.

Często mówi się, że wzorce projektowe stanowią gotowe rozwiązanie problemów programistycznych. Jakie to są problemy? „Jak mogę zmienić zachowanie obiektu, ale odizolować zmiany od reszty systemu?”

Wzorce GoF są rozpoznawane jako zapewniające izolację (enkapsulację) od reszty systemu, ale często trudno jest ustalić, która część systemu ma zmienność dzięki zastosowaniu ich wzorców projektowych. Zamiast postępować zgodnie z zaproponowanym przez nich schematem klasyfikacji (kreacyjnym, behawioralnym i strukturalnym), sporządziłem mapę różnic między wzorami i wymyśliłem dwa inne schematy, aby sklasyfikować ich wzorce: cykl życia i hierarchię enkapsulacji komponentów.

Jak widać z tej tabeli dla hierarchii enkapsulacji, wzorce projektowe mogą być stosowane na każdym poziomie komponentu. Ale czy miałoby to sens? Czy komponent będzie musiał zapewnić zmienność behawioralną na proponowanym poziomie kapsułkowania i czy dla tego poziomu zastosowano odpowiedni wzorzec? Jeśli odpowiedzi na te pytania nie są prawidłowe, wzorce projektowe są najprawdopodobniej źle zastosowane. To, że pionowy czop może być wbudowany w kabinę samochodu, nie czyni z niego mądrego pomysłu.

Stosując analogię do pieniędzy, wzorzec projektowy należy traktować jako rozwiązanie o wysokich kosztach kapitałowych, ale niskich kosztach operacyjnych. Wzory projektowe kosztują z góry fortunę pod względem dodatkowego kodowania, gadatliwości i wagi koncepcyjnej dzięki dodatkowej pośredniczości, którą tworzą. Mają także tendencję do blokowania innych aspektów twojego projektu. Na przykład użycie metody szablonu zmusza Cię do programowania w stylu OO.

Jeśli jednak musisz rozwiązać wiele ściśle powiązanych problemów, które różnią się na kilka małych sposobów, lub na pewno będziesz musiał znacznie zmodyfikować fragment kodu w określony sposób w przyszłości, koszty początkowe mogą być tego warte, ponieważ projektowanie Wzory zwiększają elastyczność twojego kodu. Modyfikacje lub rozwiązanie drugiego zestawu ściśle powiązanych problemów będzie o wiele łatwiejsze dzięki wzorcom niż bez.

Oba obozy mają rację - są siłą na dobre, gdy są właściwie używane, siłą na złe, jeśli są rozpryskiwane w całym miejscu.

Wzory projektowe mogą mieć talent do wciągania, ale to samo dotyczy ogólnie kodowania. Łatwo dać się uwieść, pisząc ostateczny zestaw narzędzi - musisz tylko pamiętać o YAGNI, aby nie dać się zbić z kursu, poczuć, ile struktury potrzebuje aplikacja. IMO to tylko kwestia osoby i znak jej doświadczenia / osądu.

Myślę o projektowaniu baz danych, a nie o czymś, co ciągle próbujesz zastosować w swoim kodzie. Dla mnie chodzi głównie o wspólny język dla programistów. Łatwiej jest powiedzieć „kierujemy się wzorem konstruktora” niż wyjaśniać to wszystko w kółko.

Obecnie ponownie czytam Wzorce architektury aplikacji korporacyjnych , ponieważ natrafiam na dużo kodu, który jest zgodny z jednym z wzorców z tej książki. Nie sądzę, aby celowo wybrano jeden z tych wzorców, ale zdecydowanie pomaga, jeśli można powiedzieć „ to skrypt transakcyjny ”, a wszyscy dobrze rozumieją, co to znaczy.

Ale podoba mi się pomysł, że możesz wybrać z przygotowanego katalogu wzorów, projektując nową funkcjonalność lub zupełnie nową aplikację. Po co wymyślać wszystko, jeśli istnieją sprawdzone rozwiązania niektórych problemów?