Więc „Czy wzorom projektowym brakuje funkcji językowych”? [Zamknięte]

Widziałem tutaj, na programistach, odpowiedź na to pytanie: Jak zmienia się myślenie o wzorcach projektowych i praktykach OOP w dynamicznych i słabo typowanych językach? Tam znalazłem link do artykułu z wypowiedzianym tytułem: Czy wzorce projektowe nie mają funkcji językowych . Ale tam, gdzie znalazłem fragmenty, które wydawały mi się bardzo chwytliwe i które można prawdopodobnie zweryfikować na podstawie doświadczenia, biorąc pod uwagę zachętę, na przykład:

PaulGraham powiedział: „Peter Norvig stwierdził, że 16 z 23 wzorów we wzorach projektowych było„ niewidocznych lub prostszych ”w Lisp”.

lub inne zdanie, które potwierdza to, co ostatnio widziałem, gdy ludzie próbowali symulować zajęcia w JavaScript:

Oczywiście nikt nigdy nie mówi o wzorzec „funkcji” lub wzorca „klasy”, ani o wielu innych rzeczach, które uważamy za oczywiste, ponieważ większość języków udostępnia je jako funkcje wbudowane. OTOH, programiści w czysto PrototypeOrientedLanguage? może być przydatne symulacja klas za pomocą prototypów ...

Biorę również pod uwagę, że wzorce projektowe są narzędziem komunikacji . Ponieważ nawet z moim ograniczonym doświadczeniem w tworzeniu aplikacji, widzę na przykład anty-wzorzec ( nieskuteczny i / lub przeciwny do zamierzonego ), na przykład zmuszający mały zespół PHP do nauki wzorców GoF dla małych i średnich aplikacji intranetowych. Wiem, że skala, zakres i cel mogą decydować o tym, co jest skuteczne i / lub produktywne, ale nadal nie udało mi się znaleźć technicznej informacji na ten temat.

Widziałem małe komercyjne aplikacje, które łączyły funkcjonalność z OOP i nadal są łatwe w utrzymaniu, i nie wiem, czy wiele osób potrzebowałoby np. W pythonie do napisania singletonu, ale dla mnie prosty moduł robi to samo.

Czy są więc studia, wyczerpujące artykuły lub inna forma prezentacji, która bierze pod uwagę wzorce projektowe vs. obejścia vs. prostsze sposoby wykonania tego zadania lub zamienniki według funkcji językowych?

Nie znam żadnych dogłębnych dyskusji ani badań, które uwzględniałyby wszystkie te rzeczy.

To powiedziawszy, cały argument „wzorce projektowe tylko łatają brakujące funkcje w językach OO” jest, moim zdaniem, nieco cienki. Tak, niektóre wzorce projektowe są dokładnie takie, wypełniają pewne powszechne luki, nawet nie istnieją w innym języku X. Są to zazwyczaj twoje prostsze wzorce niskiego poziomu, takie jak niektóre / wiele oryginalnych w książce GoF.

Ale wzorce projektowe wykraczają daleko poza proste, a nazywanie ich brakującymi cechami językowymi rozciąga wyobraźnię. Rzuć okiem na katalog wzorców aplikacji korporacyjnych Fowlera i zastanów się, jak by to było, gdyby były one częścią podstawowej definicji języka. Myślę, że skończyłbyś z językiem specyficznym dla domeny ( DSL ) dla aplikacji korporacyjnych (i to bardzo złożonym).

Tak właśnie jest - wzorce projektowe są sposobem na znalezienie rozwiązań wielokrotnego użytku dla konkretnych problemów (które są często stosowane w ogólnym, uniwersalnym języku). Tu również pojawia się komunikacja. Jeśli powiesz mi, że „korzystamy z Active Records”, już wiem sporo o twojej aplikacji, nie poświęcając minut na omawianie różnych podejść. Tak, wzorce projektowe robią dziury w specyfikacji języka. Czy to wszystko, co robią? Nie - nie z dystansu.

Edytować:

W pewnym sensie mówię, że wzorce pozwalają praktykującym OO myśleć na wyższym poziomie i prawie konstruować rodzaj DSL dla swojego środowiska, pozostając przy składni języka. I tak, widziałem, co się dzieje, gdy zastosujesz je wszędzie (patrz: AbstractSingletonProxyFactoryBean , tak, istnieje), lub myślę, że to jakaś srebrna kula. Chodzi o to, że choć naprawdę długo się z nimi czują, mają oni faktycznie zmniejszyć złożoność, czyniąc rzeczy przewidywalnymi / zrozumiałymi na wysokim poziomie. To bardzo różni się od bycia łatką dla błędów twojego języka.

Edycja 2 - dodano kontrprzykład AbstractSingletonProxyFactoryBean, aby wyśmiewać wzorce. Aby być całkowicie uczciwym, patrząc na światło AOP, nawet ten kontrprzykład można obronić.