Czy Gang of Four dokładnie zbadał „Przestrzeń wzorów”?

144

Odkąd po raz pierwszy dowiedziałem się o wzorach projektowych Gang of Four (GoF) , co najmniej 10 lat temu, mam wrażenie, że te 23 wzory powinny być tylko małą próbką czegoś znacznie większego, co lubię nazywać Przestrzenią Wzorów . Ta hipotetyczna przestrzeń wzorów składa się ze wszystkich godnych polecenia rozwiązań (znanych lub nieznanych) dla typowych problemów projektowych oprogramowania.

Spodziewałem się więc znacznego wzrostu liczby znanych i udokumentowanych wzorców projektowych.

To się nie wydarzyło. Ponad 20 lat po ukazaniu się książki GoF w artykule w Wikipedii wymieniono tylko 12 dodatkowych wzorów, z których większość jest znacznie mniej popularna niż oryginalne. (Nie uwzględniłem tutaj wzorców współbieżności, ponieważ dotyczą one określonego tematu).

Jakie są powody?

  • Czy zestaw wzorców GoF jest w rzeczywistości bardziej wszechstronny niż myślę?

  • Czy zainteresowanie znalezieniem nowych wzorców spadło, być może dlatego, że okazały się one mało przydatne w projektowaniu oprogramowania?

  • Coś innego?

Frank Puffer
źródło
49
Wzory są wszędzie, ale często są używane w sposób bez smaku i roboty. Z tego powodu myślę, że pomysł katalogu wzorów stał się mniej popularny.
usr
6
Zaprojektować przestrzeń? Niech ktoś tu sprowadzi Marka Rosewatera, stat!
corsiKa
16
Martin Fowler opublikował Wzory architektury aplikacji korporacyjnych w 2003 r., Dokumentując około 50 wzorców, z których wiele wciąż jest w pełni rozpoznawalnych i dobrze używanych, np. „Data Mapper”, „Plugin”, „Lazy Load”, „Service Layer” itp.
Brian Rogers
2
Eksplorowanie przestrzeni wszystkich możliwych wzorców byłoby jak w ogóle nie eksplorowanie przestrzeni możliwych wzorców. Możesz zrobić wszystko wzorem. Jeśli uczynisz wszystko wzorem, nic nie będzie wzorem, ponieważ słowo traci swoje znaczenie.
Mam nadzieję, że będzie
4
@BradThomas: Oczywiście, podobnie jak w przypadku najciekawszych pytań, ludzie mają pewne zdanie. Ale opinie przynajmniej częściowo opierają się na faktach i znalazłem wiele interesujących faktów w odpowiedziach na to pytanie, które pomogą mi i mam nadzieję, że inni ponownie przemyślą swoje opinie i dojdą do bardziej uzasadnionych.
Frank Puffer,

Odpowiedzi:

165

Kiedy ukazała się Księga, wiele osób tak myślało i podjęto wiele wysiłków, aby stworzyć „biblioteki wzorców”, a nawet „społeczności wzorców”. Nadal możesz znaleźć niektóre z nich:

Ale wtedy...

Czy zainteresowanie znalezieniem nowych wzorów spadło, może dlatego, że tak naprawdę nie są one tak przydatne w projektowaniu oprogramowania?

To bardzo. Istotą wzorców projektowych jest poprawa komunikacji między programistami, ale jeśli spróbujesz dodać więcej wzorców, szybko dojdziesz do punktu, w którym ludzie nie będą mogli ich zapamiętać, źle je zapamiętać lub nie zgodzić się, jak dokładnie powinni wyglądać, a komunikacja jest w rzeczywistości nie uległa poprawie. To się często zdarza w przypadku wzorców GoF.

Osobiście poszedłbym jeszcze dalej: projektowanie oprogramowania, szczególnie dobre projektowanie oprogramowania, jest zbyt różnorodne, aby można je było w znaczący sposób uchwycić we wzorach, szczególnie w niewielkiej liczbie wzorów, które ludzie mogą zapamiętać - i są one zbyt abstrakcyjne, aby ludzie naprawdę pamiętam więcej niż garść. Więc niewiele pomagają.

Zbyt wiele osób zakochuje się w tej koncepcji i próbuje stosować wzorce wszędzie - zwykle w wynikowym kodzie nie można znaleźć rzeczywistego projektu między wszystkimi (całkowicie bezsensownymi) Singletonami i Fabrykami Abstrakcyjnymi.

Michael Borgwardt
źródło
50
Kontrowersyjna opinia: Fabryka abstrakcyjna i tak pachnie kodem :)
MetaFight,
66
Może kontrowersyjna opinia, ale och tak ważna opinia do wyrażenia. Wzory projektowe mogą stać się przykładem nowych ubrań cesarza, w których wszyscy boimy się pytać, czy są przydatne. Dobra robota.
David Arno,
18
@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
corsiKa
11
Istotą wzorców projektowych jest poprawa komunikacji między programistami ”. Myślałem, że wzorce projektowe mają na celu rozwiązywanie problemów, które często (i często niezależnie) są napotykane przez programistów. Standardy poprawiają komunikację, a ze względu na fluktuacje (wzorce wynikające z problemów XY, wzorce uważane za anty-wzorce) wielu nie uważa wzorców projektowych za standardy. Wzorce projektowe dobrze wskazują na brak cech językowych i uważam, że projektanci języków wdrażają te poprawki problemów, zanim staną się wzorami projektowymi. Nie
wierz
11
@ChrisW Nie rozumiem, o co ci chodzi ... Jak powiedziałem, GoF próbował przezwyciężyć niedociągnięcia OO, a zwłaszcza niedociągnięcia w C ++ 98, ponieważ był to ich język wyboru wraz z Smalltalk. W rzeczywistości napisali: „Wybór języka programowania jest ważny, ponieważ wpływa na punkt widzenia. Nasze wzorce zakładają funkcje języka na poziomie Smalltalk / C ++, a wybór ten określa, co można, a czego nie można łatwo wdrożyć”.
Shautieh
108

Mam wrażenie, że te 23 wzory powinny być tylko małą próbką czegoś znacznie większego, co lubię nazywać Przestrzenią Wzorów.

Jest to przerażające założenie, które propagują wszędzie programiści neofici, programiści, którzy myślą, że mogą napisać program po prostu łącząc wzorce oprogramowania. To nie działa w ten sposób. Jeśli istnieje taka „przestrzeń wzorcowa”, można założyć, że jej rozmiar jest faktycznie nieskończony.

Wzorce projektowe (w sensie GoF) mają tylko jeden cel: zrekompensować braki w używanym języku programowania.

Wzory projektowe nie są uniwersalne ani kompleksowe. Jeśli przejdziesz na inny, bardziej wyrazisty język programowania, większość wzorców w książce GoF stanie się zarówno niepotrzebna, jak i niepożądana.

Robert Harvey
źródło
40
„Wzorce projektowe (w sensie GoF) mają tylko jeden cel: zrekompensować braki w używanym języku programowania”. Wciąż to słyszę, ale nie widziałem jeszcze, aby było to uzasadnione. Każde domniemane uzasadnienie tego po prostu wskazuje na garść wzorców, które są łatwiejsze do wdrożenia w językach z pewnymi funkcjami - zwykle Odwiedzający i być może Singleton - i pozostawia ogromną większość wzorców nietkniętymi, sugerując po prostu, że one również mogą zostać zwolnione przez lepsze języki. Ale skąd to wiemy? Jaka funkcja językowa sprawia, że ​​Observer jest nieistotny? Łańcuch odpowiedzialności? Złożony?
Jules
56
@Jules Same funkcje pierwszej klasy eliminują sporą ich część, w tym Łańcuch Odpowiedzialności (to tylko zestawienie listy funkcji). Funkcjonalne programowanie reaktywne eliminuje wzorzec obserwatora. Wzór złożony jest po prostu mniej rygorystyczną definicją monoidów, a języki z typami klas i skupieniem się na prawach algebraicznych dają potężne narzędzia do pracy z monoidami. Mógłbym wymienić o wiele więcej, ale masz pomysł.
Jack
12
@Jules: Uważam, że oryginalna książka GoF wymieniała iterator jako wzorzec, ale teraz jego przekształcenie w funkcję języka jest zasadniczo ukończone w każdym zdalnie języku OOP.
Kevin,
9
@RubberDuck, w jaki sposób już zaimplementowany wzorzec sprawia, że ​​wzorzec jest przestarzały? Wciąż jest wdrażany wzorzec projektowy. Różne zestawy cech językowych mogą prowadzić do różnych implementacji wzorca, ale sam wzorzec nadal istnieje. Istnieją wzorce, aby ułatwić komunikację, nadając nazwy często powtarzającym się strategiom. Chodzi o to, że wywoływane są klasy .NET, ObservableSomething<T>co ułatwia zrozumienie ich celu, ponieważ używa powszechnie znanej nazwy wzorca. Wzór to pomysł, a nie dokładna implementacja.
null
29
@Jules: Co to jest program? Rozwiązanie ponownie pojawiającego się problemu. Co to jest wzorzec projektowy? Rozwiązanie ponownie pojawiającego się problemu. Dlaczego to nie jest program? Ponieważ nie możemy tego wyrazić jako program. Ergo, wzorzec projektowy jest rozwiązaniem problemu, który powraca, który powinien być raczej programem, a nie wzorcem projektowym, ale nie może być programem, ponieważ język nie jest wystarczająco ekspresyjny, aby wyrazić program. Przykład: nie tak dawno temu „wywołanie podprogramu” było wzorcem projektowym! Obecnie jest to funkcja językowa.
Jörg W Mittag
61

Myślę, że w grę wchodzą trzy czynniki.

Brak masy krytycznej

Po pierwsze, wzorzec to w zasadzie niewiele więcej niż nadanie nazwy kodowi, który implementuje określony „fragment” funkcjonalności. Jedynym sposobem, w jaki ta nazwa zapewnia prawdziwą wartość, jest to, że możesz polegać na tym, że wszyscy wiedzą, co to znaczy, więc po prostu używając nazwy, od razu rozumieją całkiem sporo o kodzie.

Jednak wzory nigdy nie ustanowiły masy krytycznej, której potrzebowali, aby to osiągnąć. Przeciwnie, AAMOF. W ciągu 20 (lub mniej więcej) lat, odkąd ukazała się książka GoF, jestem prawie pewien, że nie widziałem aż tuzina rozmów, w których wszyscy zaangażowani naprawdę znali wystarczająco dużo wzorców projektowych, aby poprawić komunikację.

Mówiąc nieco bardziej osobliwie: wzorce projektowe zawiodły, ponieważ zawiodły.

Zbyt wiele wzorów

Myślę, że drugim ważnym czynnikiem jest to, że początkowo nazwali zbyt wiele wzorów. W sporej liczbie przypadków różnice między wzorami są na tyle subtelne, że prawie niemożliwe jest stwierdzenie z prawdziwą pewnością, czy dana klasa pasuje do jednego lub drugiego wzoru (a może do obu - a może do żadnego).

Chodziło o to, abyś mógł mówić o kodzie na wyższym poziomie. Dość dużą część kodu można opisać jako implementację określonego wzorca. Po prostu używając tej wstępnie zdefiniowanej nazwy, wszyscy słuchający zwykle wiedzą tyle, ile zależy im na tym kodzie, więc możesz przejść do następnej rzeczy.

Rzeczywistość jest wręcz przeciwna. Powiedzmy, że jesteś na spotkaniu i powiedz im, że ta konkretna klasa to Fasada. Połowa ludzi na spotkaniu albo nigdy nie wiedziała, albo dawno zapomniała dokładnie, co to znaczy. Jeden z nich prosi o przypomnienie mu dokładnej różnicy między fasadą a, powiedzmy, pełnomocnikiem. Aha, a para osób, które naprawdę znają wzorce, spędza resztę spotkania, zastanawiając się, czy to naprawdę powinno być uważane za fasadę, czy „po prostu” adapter (z tym jednym facetem wciąż nalegającym, aby wydawało mu się to pełnomocnikiem).

Biorąc pod uwagę, że naprawdę chciałeś powiedzieć: „ten kod nie jest zbyt interesujący; przejdźmy dalej”, próba użycia nazwy wzorca tylko rozpraszała uwagę, a nie wartość.

Brak zainteresowania

Większość wzorców projektowych tak naprawdę nie zajmuje się interesującymi częściami kodu. Zajmują się takimi sprawami, jak: „jak stworzyć te obiekty?” I „jak sprawić, by ten obiekt z tym rozmawiał?” Zapamiętywanie nazw wzorców dla tych (a także wyżej wymienionych argumentów na temat szczegółów itp.) Po prostu wkłada dużo energii w rzeczy, o których większość programistów po prostu nie dba.

Ujmując to nieco inaczej: wzorce zajmują się tymi samymi rzeczami w wielu programach - ale tak naprawdę program jest interesujący, ponieważ różni się od innych programów.

Podsumowanie

Wzory projektowe zawiodły, ponieważ:

  1. Nie udało im się osiągnąć masy krytycznej.
  2. Rozróżnienie między wzorami było niewystarczające, aby zagwarantować przejrzystość.
  3. Przeważnie zajmowali się częściami kodu, na których i tak nikt tak naprawdę nie dbał.
Jerry Coffin
źródło
2
„... ale tak naprawdę program jest interesujący, ponieważ różni się od innych programów”. Całkowicie się zgadzam, ale za to musisz najpierw dobrze rozegrać tę samą część, może różnią się tylko trywialnym aspektem. Jeśli trochę się rozluźnisz, musisz nazwać i zidentyfikować wzorce. Jestem przekonany, że widzisz wzorce prawie wszędzie. Po prostu prawie nigdy nie przychodzą w czystej postaci, ale zawsze są mniej lub bardziej dostosowane do danego problemu.
Trilarion
5
Bardzo dobra odpowiedź.
Robert Harvey
4
@Trilarion: Och, zdaję sobie sprawę, że te części kodu muszą być napisane. Są trochę jak, powiedzmy, opony w twoim samochodzie. Prawie w ogóle potrzebujesz opon do jazdy - ale większość ludzi wciąż nie zna marki opon w swoim samochodzie. To wymaga, aby nauczyli się specjalnej terminologii dla opony z asymetrycznymi ukośnymi rowkami. Kto wie - może kiedyś uratowali mi życie, ale wciąż nie spędzam życia, ucząc się ich nazwisk.
Jerry Coffin
3
@DavidRicherby: Dobra, więc zastosujmy wersję analogii po stronie producenta. Czy to ważne, że John, który projektuje opony dla Goodyear, używa jednego słowa dla tego rodzaju rowka, ale Pierre, który pracuje dla Michelin, używa zupełnie innego słowa? Czy to ważne, że jeden używa słowa odnoszącego się tylko do rowka, a drugie słowa odnoszącego się do kompletnej opony z poziomymi rowkami po jednej stronie środkowej i ukośnymi rowkami po drugiej?
Jerry Coffin
2
@immibis: Powiedziałbym, że głównie tak, ponieśli porażkę. Powiedziałbym, że większość programistów rozpoznaje mniej niż pół tuzina wzorów. Singleton jest dobrze znany, ale tak naprawdę rzadko ma zastosowanie (w najlepszym wypadku). Nazwa „Factory” była w powszechnym użyciu na długo przed pojawieniem się „wzorów” (pamiętam jej użycie pod koniec lat siedemdziesiątych lub bardzo wczesnych osiemdziesiątych). Wzory miały tworzyć słownictwo, ale obecnie są one podobne do mojego słownictwa w języku greckim - wystarczające, aby (prawdopodobnie) wpaść w kłopoty, ale z pewnością niewystarczające, aby zamówić menu, a tym bardziej prowadzić znaczącą rozmowę.
Jerry Coffin,
35

Wzorcom brakuje abstrakcji, proste wzorce są abstrakcyjne, złożone wzorce nie są rozpoznawane, więc wzorce nie są użyteczne (z wyjątkiem kilku wzorców wysokiego poziomu).

Myślę, że Paul Graham powiedział to najlepiej:

Kiedy widzę wzorce w moich programach, uważam to za oznakę kłopotów. Kształt programu powinien odzwierciedlać tylko problem, który musi rozwiązać. Każda inna prawidłowość w kodzie jest dla mnie znakiem, że przynajmniej używam abstrakcji, które nie są wystarczająco potężne - często generuję ręcznie rozszerzenia niektórych makr, które muszę napisać.

Kiedy rozpoznasz wzorzec w kodzie, oznacza to, że coś się powtarza i powinieneś użyć lepszej abstrakcji. Jeśli nie masz lepszej abstrakcji, zastosujesz wzór jako obejście. Ponieważ nowsze języki programowania zapewniają lepsze abstrakcje, wzorce stają się znacznie mniej przydatne.
Również proste wzory są często łatwe do wyodrębnienia, a złożone wzory rzadko rozpoznawane.
Kiedy wzorzec zastępuje się abstrakcją, nie oznacza to, że koncepcja leżąca u podstaw wzorca znika, ale że pojęcie to można napisać jawnie zamiast pośrednio i że nie jest ono już specjalne w porównaniu z innym kodem i nie jest już rozpoznawalne jako wzorzec.

Siphor
źródło
2
Osobiście bardzo podoba mi się ten pomysł. Ale kod powinien być czytelny dla ludzi i ludzi takich jak wzorce. Wzory pomagają nam znaleźć drogę. Usunięcie wszystkich wzorców z naszego kodu spowoduje, że będzie nieczytelny.
Frank Puffer
2
@Frank Myślę, że skąd pochodzi PG, to, że wzorzec jest „zapachem” funkcji leżącej u podstaw, którą można wyodrębnić, a fakt, że nie wyciągnąłeś go do funkcji lub makra, powoduje powtarzanie - jak jeśli nie masz String.replacefunkcji, możesz sobie wyobrazić, że wyskakuje ona jako wzorzec, ale lepiej napisać ją raz, niż kontynuować jej implementację. Zgadzam się, że jeśli nie nazwiesz tych rzeczy poprawnie, utrudni to czytanie, ale gdy zrobisz to poprawnie, kod odczyta bardziej deklaratywnie IMO (np. getOrElseStyl monad opcji vs sprawdzanie wartości zerowej)
inny zapis
11
Cytat Paula Grahama dotyczył utrzymania SUCHYCH rozwiązań, co różni się od idei „wzorca” GoF. Pomysł GoF polegał na nadawaniu nazw najczęściej używanym rozwiązaniom. Robiliśmy to już na długo przed opublikowaniem książki przez GoF. Na przykład mogę powiedzieć mojemu współpracownikowi, że użyję kolejki , a mój współpracownik natychmiast wie, o czym mówię, bez konieczności wyjaśniania szczegółów tego, co robi kolejka i jak działa. Ale zobacz doskonałą odpowiedź Michaela Borgwardta powyżej.
Solomon Slow
10
Moim zdaniem ta odpowiedź nie rozumie, jakie są wzorce. Wzorzec projektowy jest często spotykanym rozwiązaniem typowego problemu. To nie jest powielanie kodu. Powiedz, weź iterator. Rozwiązujesz problem wyodrębniania kontenera, dzięki czemu możesz przechodzić przez znajdujące się w nim elementy niezależnie od tego, czym jest kontener. W ten sposób tworzysz klasę iteratora, która robi to dla każdego z twoich kontenerów i sprawia, że ​​implementują wspólny interfejs. Co tu streścić? Iterator jest już abstrakcją. I oczywiście jest różnie zaimplementowany dla wszystkich kontenerów, więc nie ma powielania kodu.
Malcolm,
3
Kluczową częścią cytatu Grahama jest to, że często generuję ręcznie rozszerzenia niektórych makr, które muszę napisać. Dotyczy to w szczególności makr Lisp. Jest tylko tyle abstrakcji, którą można zrobić bez makr.
Bart van Nierop
13

Chociaż w większości zgadzam się z tym, co odpowiedzieli tu inni, osobiście uważam, że głównym powodem nie rosnącej liczby wzorów jest to, że wzory tracą swoje znaczenie, gdy jest ich niezliczona liczba. Zaletą tych kilku wzorów jest to, że obejmują one wiele domen problemowych w standardowy sposób. Gdybyś skupił się na niekończącej się domenie wzorców, skończyłbyś się bez wzorca. To trochę jak „jak długa jest linia brzegowa wyspy?”. Jeśli mierzysz na mapie, masz przyzwoitą liczbę. Ale jeśli spróbujesz być bardziej dokładny i uzyskasz lepszą rozdzielczość, przekonasz się, że długość rośnie coraz bardziej do nieskończoności (lub niepewności; jak zmierzyłbyś dokładną granicę z pływami i na poziomie atomowym?).

qwerty_so
źródło
1
Tak, wzory mogą działać tylko wtedy, gdy nie ma ich zbyt wiele. Ale dlaczego te GoF są nadal najbardziej popularne? Niektóre z nich są obecnie uważane przez wielu za antypatterny (Singleton, Builder itp.). Powinno to zrobić miejsce dla nowych, bardziej przydatnych wzorów bez zwiększania całkowitej liczby.
Frank Puffer
2
Myślę, że to jak 10 przykazań. Źródło jest tylko 2 znaki z dala (GOF, GOE, BÓG) xD
qwerty_so
9
Tak i czasami wydaje się, że współczesna inżynieria oprogramowania odnosi się do GoF, podobnie jak średniowieczna scholastyka odnosi się do Arystotelesa.
Frank Puffer
11

Coś, o czym żadna z pozostałych odpowiedzi nie wspomina, że ​​jest również istotne:

Wzrost liczby języków pisanych dynamicznie.

Kiedy książka ukazała się po raz pierwszy, istniała poważna dyskusja, że ​​Java jest po prostu zbyt wolna, aby móc naprawdę pracować. Teraz Java jest często używana w bardziej ekspresyjnych językach ze względu na jej szybkość. Być może Ruby, Python, JavaScript i in. Są wciąż zbyt wolne dla niektórych ważnych klas aplikacji, ale ogólnie są wystarczająco szybkie do większości celów. JavaScript przynajmniej przyspiesza, mimo że w każdym wydaniu jest więcej funkcji.

Oryginalna książka GoF miała wzory zarówno w smalltalk, jak i c ++, a jeśli pamięć służy, wzory były zawsze krótsze w smalltalk, a czasem znacznie. Niektóre funkcje klasycznych wzorców projektowych są naprawdę sposobami dodawania dynamicznych funkcji do systemu o typie statycznym (jak już omówiony AbstractFactory, w którym tworzysz poprawną klasę na podstawie danych wykonawczych). Inne są tak dużo krótsze w dynamicznych językach, że po prostu łączą się w idiomatyczne użycie samego języka.

Jared Smith
źródło
10

To się stało. Wydano dziesiątki, jeśli nie setki książek, które wyglądały jak próba zredukowania całej informatyki do wzorców projektowych, gdy wydawcy i autorzy próbowali wskoczyć (lub stworzyć) kolejny nurt. Mam ich półkę. Nigdy nie konsultowałem się od pierwszego zeskanowania, i tak, byłem frajerem, ponieważ było niewiele lub nic tam nie było żadnego rzeczywistego zastosowania lub nie było to jeszcze dobrze znane (patrz na przykład Obiekt Obiekt, który jest niczym więcej niż trzecią normalną formą wyrażoną ponad kilkanaście stron zamiast jednego akapitu), a ponieważ oczywiście im mniej wzorów, tym lepiej: kwestia, która wymknęła się większości praktykujących. Rzeczywiście, kiedy zamieściłem obalenie Type Type, polecono mi przekształcić tekst jako wzorzec projektowy.Prawdziwa historia. Co pokazuje także inną wadę projektu: brak mechanizmu przeglądu, wykluczenia lub odrzucenia.

W rzeczywistości GoF nie próbował „dokładnie zbadać Wzorów Projektowych”. Zamiast tego zaangażowali się w znacznie większy projekt: wprowadzenie „języka wzorcowego” do CS, ze wszystkimi jego dziwnymi arkanicznymi notacjami Sił, Uczestników itp., Które po prostu zawiodły, ponieważ były zasadniczo błędnie rozumiane, a także były bezcelowe.

Co oni nie osiągnąć, co było przydatne, to dwie rzeczy:

  • opublikuj kilka przydatnych sztuczek, takich jak wzorzec użytkownika
  • podaj standardowy zestaw nazw, które w dużej mierze utknęły: fabryka, adapter, iterator ... Jeśli spojrzysz na CORBA, który został zaprojektowany wcześniej, zobaczysz wartość tego: wszelkiego rodzaju „obcych” nazw, takich jak Interceptor , Sługa, broker, ...

Inną przydatną koncepcją, która się pojawiła, był „anty-wzór”, np. „Loguj i rzucaj”. Projekt, podobnie jak wiele modnych w CS, został wykolejeni przez własną ewangelizację i przez pomyłkę przyjęty jako kolejna religia CS, i poszedł w ślady większości takich religii: użyteczne w częściach, ale z pewnością „bez srebrnej kuli” ((c ) Fred Brooks, 1965). Smutne, że musimy odkrywać to na nowo co kilka lat.

użytkownik207421
źródło
Czy to nadal smutne, że zakończyło się to dyskusją (i wszystkim, co się z tym wiąże)
r3wt
1
@ r3wt Non sequitur. To, co powiedziałem, jest smutne, to słabość branży IT do myślenia, że ​​każdy nowy rozwój będzie mityczną srebrną kulą, a nawiasem mówiąc, do zniszczenia niektórych wcześniejszych prac.
user207421,
2
spójrz na to z innej perspektywy. Nie jest mi smutno czytając twoją odpowiedź, ucząc się nie powtarzać błędu. więc to, co uważasz za oczywiste, jest bardzo przydatne dla innych.
r3wt
6

Było / jest kilka książek zatytułowanych PLoP ( Pattern Languages ​​of Program Design ), z których każda jest antologią artykułów prezentowanych na dorocznej konferencji .

Czytając książki, odkryłem, że niektóre wzory były dla mnie interesujące i nowe, niektóre ze standardów (np. „Pół obiekt plus protokół”).

Więc nie, kolekcja GoF nie była wyczerpująca i zainspirowała / zainspirowała ludzi do zbierania / opisywania / odkrywania / wymyślania nowych.

„Tylko 12 dodatkowych wzorów wymienionych w artykule w Wikipedii” prawdopodobnie nie jest również kompletnym zbiorem: tzn. Istnieją inne udokumentowane gdzie indziej, np. W książkach PLoP, a może także gdzie indziej.

ChrisW
źródło
Tak, możesz znaleźć opisy setek wzorów, jeśli ich szukasz. Ale żaden z nich nie wydaje się być tak popularny jak GoF.
Frank Puffer,
To dlatego, że lubiłem czytać książkę GoF, że czytałem więcej (książki), kiedy zostały opublikowane (później).
ChrisW,
1
@FrankPuffer Założę się, że wzory są popularne, nawet jeśli nie są to imiona.
dcorking
5

Książka Gang of Four (GoF) zawiera większość wzorów, które doświadczony programista w niefunkcjonalnym języku ma w swoim pasku narzędzi. To jest jak podstawowy zestaw narzędzi, z których wszyscy budowniczowie wiedzą, jak korzystać. Podstawowym wkładem książki było nadanie dobrze zdefiniowanej nazwy wzorcom, które były powszechnie używane w tym czasie przez najbardziej doświadczonych programistów, a tym samym pomoc w komunikacji między programistami omawiającymi opcje projektowania.

Oczekujesz, że elektryk będzie miał narzędzia, których nie ma normalny konstruktor, podobnie możesz oczekiwać od programisty WPF, który zna wzorce projektowe dla „Właściwości zależności”, lub „programisty SQL”, który zna wzorzec projektowy do używania wyzwalaczy do tworzyć dane audytu.

Nie uważamy ich jednak za „wzorce projektowe”, ponieważ są one używane tylko z jedną technologią.

Kolejne wzorce projektowania modemu to: „Refaktoryzacja, ulepszanie projektowania istniejącego kodu (Martin Fowler)” i „Clean Code: Handbook of Agile Software Craftsmanship (Robert C. Martin) ”. Obie te książki przedstawiają treść jako dokonane transformacje do obecnego kodu, a nie jako „projekt wielokrotnego użytku w puszkach”, jednak są one w równym stopniu „wzorami projektowymi”.

Ian
źródło
3

Oto wywiad z Erichem Gammą, w którym zastanawia się nad ich wyborem wzorców i tym, co zmieniliby dzisiaj (dobrze dzisiaj 10 lat temu, haha).

http://www.informit.com/articles/article.aspx?p=1404056

Larry: Jak przefakturowałbyś „Wzory projektowe”?

Erich: Zrobiliśmy to ćwiczenie w 2005 roku. Oto kilka notatek z naszej sesji. Odkryliśmy, że zasady projektowania obiektowego i większość wzorów nie zmieniła się od tego czasu. Chcieliśmy zmienić kategoryzację, dodać nowych członków, a także porzucić niektóre wzorce. Większość dyskusji dotyczyła zmiany kategoryzacji, aw szczególności wzorów, które należy pominąć.

Dyskutując, które wzory należy upuścić, okazało się, że nadal je wszystkie kochamy. (Nie bardzo - opowiadam się za upuszczeniem Singletona. Jego użycie jest prawie zawsze zapachem projektu).

Oto kilka zmian:

  • Tłumacz ustny i waga muchowa powinny zostać przeniesione do osobnej kategorii, którą określiliśmy mianem „Inne / złożone”, ponieważ tak naprawdę są innymi zwierzętami niż inne wzorce. Metoda fabryczna zostałaby uogólniona na Fabryczną.
  • Kategorie to: Core, Creation, Peripheral i Other. Chodzi tutaj o podkreślenie ważnych wzorów i oddzielenie ich od rzadziej używanych.
  • Nowymi członkami są: Obiekt zerowy, Obiekt typu, Wstrzykiwanie zależności oraz Obiekt / Interfejs rozszerzenia (patrz „Obiekt rozszerzenia” w Językach wzorców Projektu Programu 3, Addison-Wesley, 1997).
  • Były to kategorie:
    • Rdzeń: Kompozyt, Strategia, Stan, Dowodzenie, Iterator, Proxy, Metoda szablonu, Fasada
    • Kreacja: fabryka, prototyp, konstruktor, wstrzykiwanie zależności
    • Urządzenia peryferyjne: Fabryka abstrakcyjna, gość, dekorator, mediator, obiekt typu, obiekt zerowy, obiekt rozszerzenia
    • Inne: Flyweight, Interpreter
akuhn
źródło
Dlaczego głosujesz za mną? Proszę wyjaśnić w komentarzu, abym mógł poprawić odpowiedź.
akuhn
3

Rzeczywiste wzorce w książce są czasami bardzo przydatne, ale w rzeczywistości są to po prostu przykłady potężniejszego narzędzia, które daje ci książka: głębokie zrozumienie, kiedy i gdzie lepiej wyciąć kod monolityczny w niezależnych częściach oddzielonych i regulowanych przez interfejs .

Kiedy uczysz się tej umiejętności, zdajesz sobie sprawę, że nie musisz pamiętać dokładnych szczegółów każdego pojedynczego wzoru, ponieważ zawsze możesz wyciąć wdrażane rozwiązanie w sposób, który najlepiej pasuje do jego celu. Pomysł zapisywania coraz większej liczby wzorów wydaje się bardzo akademicki i bezcelowy.

lud1977
źródło
Dobra uwaga, ale wątpię, aby wiele osób rozumiało książkę (lub ogólnie wzorce) w ten sposób.
Frank Puffer
@ lud1977, jeśli nie nagrywamy historii, co zapobiega wpadaniu przyszłości w te same pułapki? dlatego zawsze należy to nagrywać. to nie ma sensu.
r3wt
2

Spodziewałem się więc znacznego wzrostu liczby znanych i udokumentowanych wzorców projektowych.

To się nie wydarzyło. Ponad 20 lat po ukazaniu się książki GoF w artykule w Wikipedii wymieniono tylko 12 dodatkowych wzorów, z których większość jest znacznie mniej popularna niż oryginalne. (Nie uwzględniłem tutaj wzorców współbieżności, ponieważ dotyczą one określonego tematu).

Książka GoF i Wikipedia nie są jedynym źródłem znanych wzorców projektowych. Jeśli po prostu wyszukujesz „wzorce projektowe” w Amazon.com, otrzymujesz setki książek (spróbuj tego wyszukiwania ). Sądzę, że podają tylko najbardziej znany wzorzec w artykule na Wikipedii .

Problemem nie jest to, że nie ma wystarczającej liczby udokumentowanych wzorców projektowych. Raczej jest ich tak wiele, że nikt nie może zapamiętać ich wszystkich, a większość programistów rozpoznaje tylko kilka. W tym momencie załamuje się duża obietnica wspólnego języka wzorców.

iluwatar
źródło
-1

Prawdopodobnie istnieje wiele konstrukcji, o których jeszcze nie pomyślano. Tak długo, jak ludzie opracowują oprogramowanie, pojawią się wyzwania projektowe do pokonania. Niektóre z nich mogą być rozwiązane za pomocą sprytnych nowych wzorów, z których inni mogliby skorzystać.

Języki programowania rozwinęły się i posunęły do ​​wyodrębnienia najczęściej używanych wzorców. Wzory te nadal istnieją w projektowaniu języków. Dlatego mogą być dzisiaj zignorowani, ale to nie czyni ich nieważnymi.

Czy wiedza o tym, jak zbudować dom, nagle przestaje mieć znaczenie, gdy mamy roboty, które mogą to dla nas zrobić? Twierdziłbym, że nie, nie jest. Jest to mniej istotne, pewne - i prawdopodobnie o wiele mniej satysfakcjonujące w nauce, ponieważ popyt gwałtownie spadł i nikt inny go nie studiuje.

Więc nie, nie wierzę, że przestrzeń wzorów, jak ją nazywacie, została wyczerpana. Jak wskazała inna odpowiedź, prawdopodobnie będzie nieskończona. Ale wraz ze spadkiem zapotrzebowania na projektowanie systemów, wraz ze wzrostem wysokości naszej wieży abstrakcji i mocy naszych języków programowania - coraz mniej osób budujących na najwyższych kondygnacjach zwróci uwagę na szczegóły budowy wieży .

Tim
źródło
-2

Wzorce są nieskończone .. Możesz dostosować każdy wzorzec lub mieszać n dopasować, aby utworzyć nowe. Wzorce integracji korporacyjnej są również dobrze zdefiniowane .. więc tak, gof wziął problem z dokumentowaniem wzorców za pomocą uml i stworzył standard ich wyjaśniania .. Ale dla każdej domeny ewoluują wzorce i zmieniają się one także dla ekspresyjnego języka, takiego jak python lub scala ..

Marut Singh
źródło