Czy obecnie wzorce projektowe są naprawdę niezbędne?

Czytałem „Coders at Work” i stanąłem wobec faktu, że niektórzy profesjonaliści, z którymi przeprowadzono wywiady w książce, nie są tak entuzjastycznie nastawieni do wzorów.

Myślę, że istnieją 2 główne powody:

1. Wzory projektowe zmuszają nas do myślenia w ich kategoriach. Innymi słowy, prawie niemożliwe jest wynalezienie czegoś nowego (może lepszego).

2. Wzory projektowe nie są wieczne. Języki i technologie zmieniają się szybko; dlatego wzorce projektowe staną się w końcu nieistotne.

Może więc ważniejsze jest, aby nauczyć się poprawnie programować bez żadnych konkretnych wzorców i nie uczyć się ich.

Chodziło również o to, że zwykle, gdy ludzie napotykają problem i nie mają dużo czasu, próbują użyć wzoru. Oznacza to kopiowanie i wklejanie istniejącego kodu do projektu z niewielkimi zmianami, aby go uruchomić. Gdy nadchodzi czas zmiany lub dodania czegoś, programista nie wie, od czego zacząć, ponieważ nie jest to jego kod i nie jest on dogłębnie z nim zaznajomiony.

Za moje pieniądze myślę, że wszyscy nie rozumieją wzorców projektowych. Rzadko siedzę i zastanawiam się, jakiego wzoru powinienem użyć w danej sytuacji. Poza tym korzystałem z większości tych wzorów na długo zanim wiedziałem, że mają nazwy.

Potęga wzorców projektowych jest w komunikacji. O wiele szybciej jest mi powiedzieć „użyć do tego Strategii” niż szczegółowo opisać to, co sugeruję. O wiele łatwiej jest nam omawiać zalety modeli domeny tłuszczowej w porównaniu ze skryptami transakcyjnymi, jeśli wszyscy wiemy, co oznaczają te dwa terminy. I tak dalej.

A co najważniejsze, jeśli nazwałem klasę FooBuilder, to wiesz, że używam wzorca Builder do generowania mojego Foo.

Nawet jeśli nie wiesz, o czym mówię, kiedy mówię „Wzorzec obserwatora jest do tego idealny”, będziesz w stanie łatwo przejść do wyszukiwarki Google.

W tym sensie siła wzorów nigdy nie zniknie.

Wzorce projektowe to wzrost ekspresyjnej mocy wspólnego języka, którego używamy jako ludzie oprogramowania. Ten wspólny język nie jest niezbędny, ale sprawia, że ​​wiele popularnych rozwiązań problemów jest łatwiejszych i szybszych do wyrażenia. Na przykład dużo łatwiej jest rozmawiać o Singletonach niż o „klasach, w których mamy mieć tylko jedną instancję, ale których nie można uczynić statycznymi i globalnymi”.

Rozwiązania, które zapewniają wzorce projektowe, są przydatne, ale są to rozwiązania, o których zapewne już pomyślałeś, gdy napotkasz problemy, które rozwiązują. Aby zrozumieć wzorce projektowe, wymagany jest pewien poziom dojrzałości - jeśli nigdy nie musiałeś rozwiązać problemu, nie zobaczysz wartości ani zainteresowania rozwiązaniem.

Wzory służą dwóm podstawowym celom:

• Rozwiązywanie napięć przewidywalnie : Wzorce zostały zaprojektowane w celu rozwiązania określonego zestawu napięć w znany sposób. Kent Beck, autor Smalltalk Best Practice Patterns , opisuje wzorce jako sposób na powtórzenie decyzji, którą podjąłby ekspert w podobnych okolicznościach. Dopóki napięcia pozostaną takie same (i często tak robią), wzory, które je rozwiążą, pozostaną użyteczne.

• Mnożnik siły komunikacji : Wzory pozwalają nam niewiele powiedzieć. Wykorzystują niewielki zestaw potężnych, dobrze zrozumiałych koncepcji, które można zastosować w wielu różnych obszarach problemowych. Odpowiedź @ pdr jest martwa na temat komunikatywnej wartości wzorców.

Myślę, że twierdzenie, że wzorce projektowe utrudniają innowacje, jest całkowicie fałszywe. Powinieneś wiedzieć, gdziekolwiek już istnieje, więc nie musisz wymyślać koła na nowo. Ponieważ są tymczasowe, wzorce jako całość dotyczą systemów OOP i nie są powiązane z żadną konkretną platformą lub językiem.

Teraz nie lubię, gdy ludzie mówią o wzorach, że niektórzy mają na ich punkcie obsesję. Kiedyś miałem klienta, który poprosił mnie o „dołączenie co najmniej dwóch kolejnych wzorów” (WTF ?!), ponieważ z powodu braku modnych słów w moim kodzie nie wyglądało to wystarczająco przedsiębiorczo.

Być może koncepcja anty-wzorów jest niemądra. Nie uważam studiowania wzorców projektowych za kluczowy krok do zostania inżynierem oprogramowania. Projektowanie oprogramowania jest ważne, często zastrzeżone jako przywilej architekta oprogramowania w projekcie, ale realistycznie coś, co można wypracować w drodze konsensusu w przysłowiowym „dobrze zżelowanym” zespole.

Ale wzorce projektowe i anty-wzorce stanowią źródło tych dyskusji. Należy docenić lekcje rzeczy, które działały dobrze (lub nie) i jak wykorzystać (lub złagodzić) konsekwencje wyborów projektowych. Dobry zespół mógłby wymyślić własne słownictwo do takich dyskusji, ale tak naprawdę nie jest tak źle odwoływać się do standardów defacto wypracowanych przez autorów, którzy tam byli, to zrobili.

Istnieją dwa rodzaje wzorców projektowych:

1. Uniwersalne wzorce , w których chodzi o to, jak organizować złożone programy, aby w ogóle je zrozumieć. Nie znikają, choć można odkryć ich więcej.
2. Wzorce sytuacyjne , które są tak związane z poszczególnymi siłami wywołanymi przez ograniczenia (np. Język programowania), że gdy siły te się zmieniają, stają się nieistotne.

OK, prawdopodobnie wszystkie wzorce są w pewnym stopniu sytuacyjne, ale w przypadku niektórych sił pochodzą one ze świata rzeczywistego, a w przypadku innych siły pochodzą z narzędzi. Narzędzia zmieniają się znacznie szybciej niż w prawdziwym świecie.

Czytanie o wzorach projektowych jest jak uczenie się matematyki zamiast jej odkrywania na nowo. Żadne nie powstrzymuje cię przed poczynieniem wielkich postępów w określonej dziedzinie, gdy dobrze zrozumiesz, co się działo wcześniej. Myślisz, że Rieman nigdy nie czytał Euclida?

Korzyścią jest projektowanie wzorców, gdy skracają czas, jaki koledzy lub klienci spędzają na myśleniu „Jak to działa?”. Chociaż nie ma sensu egzekwowanie standardu ze względu na standaryzację, jeśli istnieje jeden powszechny i ​​dobrze zrozumiały sposób zrobienia czegoś, za każdym razem, gdy programista szuka tego wzorca oczekując go i robi, wykonałeś ich i swoje zadania łatwiej.

Uważam, że czwórka z nich sama klasyfikuje wzorce projektowe jako

wspólne rozwiązanie często występującego problemu *

Tak, wzorce są istotne, gdy występuje ten sam typ problemu. I to prowadzi nas do problemu z terminem „wzorzec projektowy”. Wzór to coś, co można rozpoznać wielokrotnie. Tak więc w rzeczywistości nie ma wzoru wzorów, jest wzór problemów.

Niektóre języki programowania mogą mieć natywne rozwiązania niektórych z tych problemów. W samej książce „Wzorce projektowe” wspomina się, że wzorzec gościa ma niewielką wartość, jeśli używasz CLOS, ponieważ wiele wysyłek jest natywnie obsługiwanych przez CLOS, właśnie ten problem, który próbuje rozwiązać wzór gościa.

Ponadto .NET Framework ma wbudowany mechanizm zdarzeń do publikowania zdarzeń wielu słuchaczom, dzięki czemu wzorzec Observer jest mniej istotny w tym kontekście.

Zmiana z aplikacji komputerowych na aplikacje internetowe ** zmienia również rodzaj problemów programistycznych, które musimy rozwiązać. Wiele wzorców z książki „Wzory projektowe” dotyczy aplikacji komputerowych, ale nie tyle aplikacji internetowych. Oczywiście w przypadku aplikacji jednostronicowych wzorce te mogą być znowu odpowiednie po stronie klienta.

Ale wzorce projektowe i książki takie jak „Wzory projektowe” lub „Wzory architektury aplikacji korporacyjnych” mają ogromną wartość, gdy jesteś początkującym programistą i po raz pierwszy napotykasz nowy rodzaj problemu; ponieważ po raz pierwszy zostałem poproszony o wdrożenie funkcji Cofnij. Gdyby nie książka „Wzory projektowe”, moja implementacja byłaby prawdopodobnie czymś w rodzaju przechowywania migawki danych po każdej operacji zmieniającej stan *** - podejście bardzo podatne na błędy i okropnie nieefektywne.

Tak więc, niektóre wzorce stają się z czasem mniej istotne, a kiedy stajesz się doświadczonym programistą, mniej o nich myślisz. Ale dla początkującego są one cenne, o ile pamiętasz, że są sposobem na rozwiązanie problemu - a nie dążeniem do korzystania z jak największej liczby.

* cytat może nie być w 100% dokładny, ponieważ pochodzi z pamięci

** z mojego doświadczenia wynika, że ​​bardzo często przedsiębiorstwa wybierają mechanizmy dostarczania stron internetowych do wewnętrznych aplikacji biznesowych.

*** po nauczeniu się programowania funkcjonalnego i struktur danych funkcjonalnych, to może być sposób, w jaki mógłbym to dziś rozwiązać.

Niewolnicze przestrzeganie wzorców projektowych może być szkodliwe - wzorce są udokumentowanymi rozwiązaniami typowych problemów, ale nie są instrukcjami obsługi. Jednak fakt, że są one omawiane szczegółowo, aw niektórych przypadkach stosowane poza skutecznymi domenami problemowymi, nie oznacza, że ​​nie mają one żadnej wartości. Są to zbiór zasad - nazywają to ramą - z których należy korzystać przy projektowaniu architektury programu, pozwalając architektowi na wyobrażenie sobie, jak chciałby zobaczyć rozwiązanie. Dobry zespół programistów postrzega je jako podstawę funkcjonalności, a nie specyfikację funkcjonalną.