Czy programowanie funkcjonalne zastępuje wzorce projektowe GoF?

Czy jest jakaś prawda w twierdzeniu, że programowanie funkcjonalne eliminuje potrzebę wzorców projektowych OOP?

W przypadku programowania funkcyjnego, nie będziesz czytać książek oo wzorców projektowych, będziesz czytać inne książki o wzorcach projektowych FP.

Język agnostic

Typowy wzorzec projektowy OOP i jego funkcjonalny odpowiednik?

Powyższe nie powinno istnieć. To jak prośba o fragment kodu proceduralnego przepisany jako kod OO. Hmmm... Jeśli przetłumaczę oryginalny Fortran (lub C) na Javę, nie zrobiłem nic więcej niż przetłumaczyć. Jeśli całkowicie przepiszę go do paradygmatu OO, nie będzie już wyglądał jak oryginalny Fortran lub C -- będzie nierozpoznawalny.

Nie ma prostego odwzorowania od projektu OO do projektu funkcjonalnego. Są bardzo różne sposoby patrzenia na problem.

Programowanie funkcyjne (jak wszystkie style programowania) ma wzorce projektowe. Relacyjne bazy danych mają wzorce projektowe, OO ma wzorce projektowe, programowanie proceduralne ma wzorce projektowe. Wszystko ma wzorce projektowe, nawet architektura budynków.

Komentarze Briana na temat ścisłego związku między językiem a wzorcem są do rzeczy,

Brakującą częścią tej dyskusji jest pojęcie idiomu. Duży wpływ miała tu książka copliena " Advanced C++". Na długo przed odkryciem Christophera Alexandra i Kolumny Bez Nazwy (i nie można rozsądnie mówić o wzorcach bez czytania Alexandra), mówił o znaczeniu opanowania idiomu w prawdziwej nauce języka. Używał string copy w C jako przykład, while (*from++ = * to++); możesz to zobaczyć jako bandaid dla brakującej funkcji języka( lub funkcji biblioteki), ale to, co naprawdę się w tym liczy, to to, że jest to większa jednostka myśli lub ekspresji niż jakakolwiek z jej części.

To właśnie próbują robić wzorce i języki, aby umożliwić nam bardziej zwięzłe wyrażanie naszych intencji. Im bogatsze jednostki myśli, tym bardziej złożone myśli można wyrazić. Posiadanie bogatego, współdzielonego słownictwa w różnych skalach-od systemu architektura w dół do nieco twidling-pozwala nam na bardziej inteligentne rozmowy, i myśli o tym, co powinniśmy robić.

Możemy również, jako jednostki, uczyć się. I to jest cały cel ćwiczenia. Każdy z nas potrafi zrozumieć i używać rzeczy, których nigdy nie potrafilibyśmy o sobie myśleć. Języki, frameworki, biblioteki, wzorce, idiomy itd. mają swoje miejsce w dzieleniu się intelektualnym bogactwem.

Książka GOF wyraźnie wiąże się z OOP - tytuł to wzorce projektowe-elementy oprogramowania Wielokrotnego Użytku zorientowanego obiektowo (akcent mine.)

Design Patterns in Dynamic Programming autorstwa Petera Norviga ma przemyślane omówienie tego ogólnego tematu, choć o językach "dynamicznych" zamiast "funkcjonalnych" (jest nakładanie się).

Oto kolejny link, omawiający ten temat: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

W swoim wpisie na blogu Edward opisuje wszystkie 23 oryginalne wzorce GoF pod względem Haskella.

Kiedy spróbujesz spojrzeć na to na poziomie " wzorców projektowych "(ogólnie) i "FP kontra OOP", odpowiedzi, które znajdziesz, będą w najlepszym razie mroczne.

Przejdź głębiej na obu osiach i zastanów się nad specyficznymi wzorcami projektowymi i nad specyficznymi cechami języka , a wszystko stanie się jaśniejsze.

Więc np. jakieś konkretne wzorce, np. Visitor, Strategia, polecenie i Observer definitywnie zmienić lub zniknąć, gdy używanie języka z algebraicznymi typami danych i dopasowywaniem wzorców, zamknięcia, Funkcje pierwszej klasy , itd. Niektóre inne wzory z książki GoF nadal "trzymać się", choć.

Ogólnie rzecz biorąc, powiedziałbym, że z czasem konkretne wzorce są eliminowane przez nowe (lub po prostu rosnącą popularność) funkcje językowe. Jest to naturalny bieg projektowania języka; w miarę jak języki stają się bardziej zaawansowane, abstrakcje, które wcześniej można było wywołać tylko w książki z przykładami stają się teraz aplikacjami określonej funkcji językowej lub biblioteki.

(Na bok: oto ostatni blog, który napisałem, który ma inne linki do dalszej dyskusji na temat FP i wzorców projektowych.)

Prezentacja Norviga nawiązuje do analizy wszystkich wzorców GoF, którą zrobili, i mówią, że 16 z 23 wzorców miało prostsze implementacje w językach funkcyjnych lub po prostu były częścią języka. Prawdopodobnie więc przynajmniej siedem z nich albo było a) równie skomplikowanych, albo b) nieobecnych w języku. Niestety dla nas nie są one wymienione!

Myślę, że jest jasne, że większość "kreacyjnych " lub" strukturalnych " wzorców w GoF to tylko sztuczki, aby uzyskać prymitywne systemy typu w Javie lub C++, aby robić to, co chcesz. Ale reszta jest warta rozważenia, bez względu na to, w jakim języku programujesz.

Jeden może być prototypem; chociaż jest to podstawowe pojęcie JavaScript, musi być zaimplementowany od podstaw w innych językach.

Jednym z moich ulubionych wzorców jest NULL Object pattern: reprezentują brak czegoś jako obiektu, który nie robi odpowiedniego rodzaju niczego. Może to być łatwiejsze do modelowania w języku funkcjonalnym. Jednak prawdziwym osiągnięciem jest zmiana perspektywy.

Powiedziałbym, że jeśli masz Język taki jak Lisp z obsługą makr, możesz zbudować własne abstrakcje specyficzne dla domeny, abstrakcje, które często są znacznie lepsze niż ogólne rozwiązania idiomu.

I nawet rozwiązania wzorców projektowych oo są specyficzne dla języka. Wzorce projektowe to rozwiązania typowych problemów, których język programowania nie rozwiązuje za Ciebie. W Javie wzór Singletona rozwiązuje problem "jednego z czegoś" (uproszczony). W Scali oprócz klasy masz konstrukcję najwyższego poziomu o nazwie Object. Jest leniwie utworzony i jest tylko jeden. Nie musisz używać wzoru Singletona, aby uzyskać Singleton. To część języka.

Jak mówili inni, istnieją wzorce specyficzne dla programowania funkcyjnego. Myślę, że kwestia pozbycia się wzorców projektowych to nie tyle kwestia przejścia na funkcjonalność, co kwestia cech języka .

Zobacz, jak Scala radzi sobie z "wzorcem Singletona": po prostu deklarujesz obiekt zamiast klasy. Inna funkcja, dopasowanie wzorca, pomaga uniknąć clunkiness wzorca odwiedzającego. Zobacz porównanie proszę.: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

A Scala, podobnie jak F#, jest fuzją OO-functional. Nie wiem jak F # ale pewnie ma takie funkcje.

Zamknięcia są obecne w języku funkcjonalnym, ale nie muszą być ograniczone do nich. Pomagają przy wzorze delegatora.

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

Języki imperatywne, takie jak Java i C#, przyjęły coś, co jest zasadniczo konstrukcją funkcjonalną, aby sobie z tym poradzić: "foreach".

Wzorce są sposobami rozwiązywania podobnych problemów, które są wielokrotnie widziane, a następnie opisywane i dokumentowane. Tak więc nie, FP nie zastąpi wzorców; jednak FP może tworzyć nowe wzorce i sprawić, że niektóre obecne wzorce "najlepszych praktyk" staną się "przestarzałe".

Wzorce projektowe GoF są recepturami obejścia kodu dla języków OO, które są potomkami Simula 67, takich jak Java i C++.

Większość "chorób" leczonych wzorcami projektowymi jest spowodowana przez:

• klasy typowane statycznie, które określają obiekty, ale same nie są obiektami;
• Ograniczenie do pojedynczej wysyłki (do wybrania metody używany jest tylko lewy argument, pozostałe argumenty są traktowane tylko jako typy statyczne: jeśli mają typy dynamiczne, to do góry do metody uporządkowania tego za pomocą podejść ad-hoc);
• rozróżnienie między regularnymi wywołaniami funkcji a obiektowymi wywołaniami funkcji, co oznacza, że funkcje obiektowe nie mogą być przekazywane jako argumenty funkcyjne, w których oczekuje się regularnych funkcji i odwrotnie; oraz
• rozróżnienie między "typami bazowymi" i "typami klasowymi".

Nie ma ani jednego z tych wzorców projektowych, który nie zniknie w systemie obiektów Common Lisp, mimo że rozwiązanie jest skonstruowany zasadniczo w taki sam sposób, jak w odpowiednim wzorze projektowym. (Co więcej, ten system obiektowy wyprzedza księgę GoF o ponad dekadę. Common Lisp stał się standardem ANSI w tym samym roku, w którym ta książka została po raz pierwszy opublikowana.)

Jeśli chodzi o programowanie funkcyjne, to od tego, czy dany język programowania funkcyjnego ma jakiś system obiektowy, zależy czy jest on wzorowany na systemach obiektowych, które korzystają z wzorców. Ten typ orientacji obiektowej nie miesza się dobrze z programowaniem funkcyjnym, ponieważ mutacja stanu znajduje się na pierwszym planie.

Budowa i dostęp bez mutacji są kompatybilne z programowaniem funkcjonalnym, a więc mogą mieć zastosowanie wzory, które mają związek z abstrakcyjnym dostępem lub konstrukcją: wzory takie jak Fabryka, Fasada, Proxy, dekorator, gość.

Z drugiej strony wzorce zachowań, takie jak stan i strategia, prawdopodobnie nie bezpośrednio Zastosuj w funkcjonalnym OOP, ponieważ mutacja stanu jest ich rdzeniem. Nie oznacza to, że nie mają zastosowania; być może w jakiś sposób stosują się w połączeniu z dowolnymi sztuczkami dostępnymi do symulacji stanu zmiennego.

Chciałbym podłączyć kilka doskonałych, ale nieco gęstych artykułów Jeremy 'ego Gibbonsa:" wzorce projektowe jako typy danych wyższego rzędu-programy generyczne "i" istota wzorca iteratora " (oba dostępne tutaj: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/).

Oba te opisują, w jaki sposób idiomatyczne konstrukcje funkcjonalne obejmują teren, który jest objęty określonymi wzorami projektowymi w innych (obiektowych) Ustawieniach.

Nie można prowadzić tej dyskusji bez poruszania systemów typów.

Główne cechy programowania funkcyjnego obejmują funkcje jako wartości pierwszej klasy, Curry, niezmienne wartości itp. Nie wydaje mi się oczywiste, że wzorce projektowe oo zbliżają się do żadnej z tych funkcji.

To dlatego, że te funkcje nie rozwiązują tych samych problemów, które robi OOP... są alternatywą dla programowania imperatywnego. Odpowiedź FP na OOP leży w systemach typu ML i Haskell... w szczególności typy sum, abstrakcyjne typy danych, Moduły ML, typy Haskell.

Ale oczywiście nadal istnieją wzorce projektowe, które nie są rozwiązywane przez języki FP. Co to jest FP odpowiednik Singletona? (Pomijając przez chwilę, że singletony są ogólnie okropnym wzorem w użyciu)

Pierwszą rzeczą, jaką robią typeklasy, jest wyeliminowanie potrzeby singletonów.

Możesz przejrzeć listę 23 i wyeliminować więcej, ale nie mam czasu do teraz.

Myślę, że tylko dwa wzorce projektowe GoF mają na celu wprowadzenie logiki programowania funkcyjnego do naturalnego języka OO. Myślę o strategii i dowodzeniu. Niektóre inne wzorce projektowe GoF mogą być modyfikowane przez programowanie funkcjonalne w celu uproszczenia projektu i zachowania celu.