Dlaczego wzorce projektowe nie są dodawane do konstrukcji języków?

Ostatnio rozmawiałem z kolegą, który wspomniał, że jego firma pracuje nad dodaniem wzorca projektowego MVC jako rozszerzenia PHP.

Wyjaśnił, że napisali kod C w celu dodania Controllers, Models and Viewsdo konstrukcji języka w celu zwiększenia wydajności.

Teraz wiem, że MVC to wzorzec projektowania architektonicznego, który jest szeroko stosowany w aplikacjach internetowych, ale wciąż muszę spotkać języki, które mają konstrukcję językową na przykład dla kontrolerów.

Integracja wzorców projektowych w języku IMHO może podkreślić znaczenie dobrego projektowania OO.

Więc dlaczego nie są najbardziej wzorce projektowe używane (MVC, fabryka, strategiczne, ... itp.) Dodać do konstrukcji języka?

Jeśli pytanie brzmi zbyt szeroko, możesz ograniczyć je tylko do PHP.

Edytować:

Nie sugeruję, że należy opracować projekt przy użyciu wzorca projektowego. Właściwie promuję metodologię prostoty, o ile działa.

Wzory projektowe są cały czas dodawane do konstrukcji językowych. Słyszałeś kiedyś o wzorcu wywołania podprogramu ? Nie? Ja też nie. Wynika to z tego, że wywołania podprogramów, które były wzorcem projektowym na początku lat 50., zostały niemal natychmiast dodane do języków. Obecnie są one nawet obecne w zestawach instrukcji maszynowych CPU.

Co z wzorcem projektowym For Loop ? Pętli while Pattern Design? Wzór przełącznika ? Object Pattern Design? Klasa wzorzec projektowy? Wszystkie zostały dodane do niektórych języków.

Niektórzy z nich są. Na przykład iteratory są funkcją języka w wielu językach i ich bibliotekach standardowych (cześć, foreach i return return). Obserwator jest również często obecny w formie zdarzeń (nie w PHP - sam musisz zarządzać subskrypcją wywołania zwrotnego). Polecenie jest podstawową funkcją WPF.

Wielu innych tak naprawdę nie skorzystałoby ze wsparcia językowego (i uczyniłoby ten język bardziej uciążliwym) - jak uprościłbyś Kontrolery, gdybyś mógł zaprojektować dla nich funkcję językową? Jako klasy korzystają z całej istniejącej infrastruktury do obsługi klas - możesz tworzyć ich instancje, przekazywać je i na przykład testować je jak każdy inny obiekt.

Jedynym składnikiem MVC, który IMO mógłby skorzystać z pewnego rodzaju wsparcia językowego, jest View (z jakimś oficjalnym silnikiem szablonów) - i jest on już obsługiwany w PHP - możesz dynamicznie tworzyć i ładować skrypty PHP (często z pewnego rodzaju przetwarzanie wstępne stosowane jako szablony).

To samo dotyczy metody fabrycznej - jak byś to uprościł, gdybyś mógł mieć jakąkolwiek funkcję językową, którą chciałeś? Jedną z cech, której brakuje w niektórych językach (takich jak C ++), jest możliwość konstruowania obiektu na podstawie nazwy tego typu, ale większość języków wyższego poziomu może to zrobić (i nie jest nawet konieczne tworzenie przydatnych metod fabrycznych). Poza tym wszystko, czego potrzebujesz, to możliwość stworzenia metody, która tworzy instancję, zwraca i obiekt.

Niektóre wzorce projektowe są rzeczywiście dodawane jako konstrukcje językowe - po prostu nie są identyfikowane jako takie, ponieważ ludzie zaczynają traktować je jako „składnię” po ich wbudowaniu. Dobrym przykładem jest obsługa wyjątków w Javie - wiele osób koduje coś podobnego jawnie jako wzorzec projektowy, jeśli nie był on częścią składni rdzenia.

Ale aby skupić się na pytaniu - istnieje wiele powodów, dla których nie chcesz dodawać zbyt wielu wzorców projektowych do języka:

• Nie jest konieczne dodawanie ich jako konstrukcji językowych - wszystkie wzorce projektowe można zaimplementować na inne sposoby
• Skomplikowałoby to język - to zły pomysł, ponieważ utrudnia naukę języka, utrudnia kompilatory i narzędzia do pisania
• Istnieją alternatywne podejścia do implementacji wielu wzorców projektowych. Wybór jednego podejścia i pobłogosławienie go jako części podstawowego języka prawdopodobnie skłoniłoby ludzi do stosowania tego podejścia w stosunku do innych (co może być znacznie lepsze w niektórych okolicznościach)
• W każdym razie nadmierne poleganie na wzorach projektowych jest prawdopodobnie złym pomysłem - projektanci języków prawdopodobnie zdają sobie sprawę, że nie powinni ich jeszcze zachęcać.

Ponadto, jeśli używasz wystarczająco mocnego języka z możliwościami metaprogramowania (np. Lisp), samodzielne rozszerzenie języka w celu zaimplementowania dowolnego wzorca projektowego staje się stosunkowo proste . Nie potrzebujesz żadnych wzorców w podstawowym języku, jeśli łatwo jest dodać własne za pomocą 5-liniowego makra.

Dlaczego najczęściej używane wzorce projektowe (MVC, fabryka, strategia itp.) Nie są dodawane do konstrukcji języka?

Większość tych wzorców można wdrożyć w większości języków programowania bez specjalnego wsparcia językowego. Weźmy na przykład MVC w Javie:

• Możesz to kodować bezpośrednio.
• Możesz wdrożyć go za pomocą generatora aplikacji ... i jednocześnie zadbać o całą masę innych płyt kotłowych.
• Możesz to zaimplementować za pomocą klas biblioteki „framework”.
• Można go zaimplementować za pomocą adnotacji i przetwarzania adnotacji statycznych lub wykonawczych.

Biorąc pod uwagę wszystkie te opcje, bezpośrednie poszerzenie języka ma niewielką wartość. I jest wiele „wad”:

• Miałoby to tendencję do zaśmiecania składni języka, (prawdopodobnie) utrudniając życie początkującym programistom.
• Sprawiałoby to, że specyfikacja języka była większa i bardziej złożona, co utrudnia implementatorom języków. (I, oczywiście, im większa specyfikacja, tym większe prawdopodobieństwo wystąpienia błędów i niespójności).
• Zawsze będzie presja, aby dodać kolejny wzór ... prowadzący do problemów / obaw dotyczących stabilności języka.
• Wspierając określone wzorce w języku, ustalasz konkretne sposoby obsługi wzorców, które mogą nie pasować do niektórych aplikacji.

Oni są.

Funkcje były wzorcem projektowym w kodzie asemblera, zanim stały się konstrukcją językową w C.

Funkcje wirtualne były wzorcem projektowym w C, zanim stały się konstrukcją językową w C ++.

Jest jednak kompromis. Jeśli wzorzec obejmuje wygenerowanie kodu typu „kocioł” (nawet kilku słów kluczowych), oznacza to, że byłaby to przydatna funkcja językowa. Ale jeśli wzór jest prosty i jasny, np. C „for (int i = 0; i <10; i ++)”, nadal jest użyteczne dla wszystkich, aby napisać to w ten sam sposób, ale nie jest znacznie dłuższy niż „dla i = 0 do 10” i ma znaczącą zaletę, że jest to oczywiste, jak to zmienić, aby uzyskać nieco inną pętlę.

Przeczytaj książkę „gang czterech”, a stanie się jasne, że:

1. Wzory projektowe w książce są właściwie dobrze znanymi konwencjami smalltalk zakodowanymi w innych językach OO.
2. Jako takie, wzorce te nie mogą być włączone do języka OO - to byłoby ponowne wdrożenie smalltalk w tych językach - lepiej jest używać smalltalk bezpośrednio
3. Dlaczego wzorce projektowe są przydatne, ponieważ nie podkreślają roli obecnie używanego języka i koncentrują się na innych kwestiach niż składnia. Kodowanie tych wzorców w języku utraci tę funkcję wzorców projektowych.
4. Prawdziwym problemem w powyższym pytaniu jest to, że nie rozumie się, że pisanie oprogramowania nie polega wyłącznie na nauce języka. Ważne jest, aby zachować wystarczającą odległość od tego, co zapewnia bezpośrednio język, i skupić się na bieżących wymaganiach.

Ponieważ wzorce projektowe są doskonale wdrażane z kodem użytkownika. Jego przykład wydarzył się tylko dlatego, że jest to PHP, ale jeśli naprawdę potrzebujesz wydajności, po prostu pracowałbyś w innym języku lub dostałeś HipHop czy coś takiego.

Funkcje językowe są skomplikowane, zarówno pod względem określania, jak i implementacji, i nie jest uzasadnione, aby tworzyć je wyłącznie w celu „Obecne idiomy to X”. Zupełnie nie zapisałeś żadnego znaczącego kodu użytkownika i na darmo.

Ech, nieaktualne pytanie, ale nie zgadzam się z wieloma odpowiedziami w zależności od tego, gdzie ustawiłeś „Wzory projektowe” na tarczy semantyki, w tym na zaakceptowaną.

W sensie książki GoF Design Patterns powiedziałbym, że to zależy. Na przykład MVC (nie jest to wzór GoF, ale pasuje do tej formy), jest całkowicie niewłaściwe do wyrażania jako konstrukcje językowe do masowego zużycia (chociaż może to mieć sens w przypadku konkretnego projektu PHP). Jako wzorzec architektoniczny istnieją ciągłe zmiany tematu i szeroka gama całkowicie uzasadnionych interpretacji dla różnych okoliczności (chociaż wielu odchodzi tak daleko od MVC, prawdopodobnie nie powinni już więcej nazywać go MVC). Na przykład w Internecie bariera http sprawia, że ​​jest to dość niewygodne dopasowanie w zależności od tego, czy próbujesz uwzględnić stronę równania (bez wątpienia boleśnie) w równaniu i tego, co uważasz za „widok” z bardziej odpowiednio ściśle po stronie serwera.

Z drugiej strony Iterator jest bardzo ogólną koncepcją, którą można zastosować na wiele różnych sposobów do wielu różnych konstrukcji.

Tam, gdzie należy ustalić, czy coś należy do projektu w języku podstawowym, nawet w języku specyficznym dla sieci po stronie serwera, IMO, jest punktem, w którym coś przekracza linię, ułatwiając robienie nieobliczalnej liczby rzeczy łatwiejsze niż wykonywanie zbyt specyficznych, ale szeroko zaimplementowanych rzeczy, takich jak wzorzec architektury dla Ciebie.