risposta-alla-domanda-sullo-sviluppo-web-bd.com

La programmazione funzionale sostituisce i modelli di progettazione GoF?

Da quando ho iniziato a studiare F # e OCaml l'anno scorso, ho letto un numero enorme di articoli che insistono sul fatto che i modelli di progettazione (specialmente in Java) sono soluzioni alternative per le funzionalità mancanti nelle lingue imperative. Un articolo che ho trovato fa un reclamo abbastanza forte :

La maggior parte delle persone che ho incontrato hanno letto il libro dei Pattern Design della Gang of Four. Qualsiasi programmatore che si rispetti da solo ti dirà che il libro è indipendente dal linguaggio e i pattern si applicano all'ingegneria del software in generale, indipendentemente dalla lingua che usi. Questa è una richiesta nobile. Sfortunatamente è molto lontano dalla verità.

I linguaggi funzionali sono estremamente espressivi. In un linguaggio funzionale non ci sono schemi di progettazione perché il linguaggio è probabilmente così di alto livello, finisci per programmare in concetti che eliminano tutti i modelli di progettazione.

Le caratteristiche principali della programmazione funzionale includono funzioni come valori di prima classe, currying, valori immutabili, ecc. Non mi sembra ovvio che OO i pattern di progettazione stiano approssando una di quelle caratteristiche.

Inoltre, nei linguaggi funzionali che supportano OOP (come F # e OCaml), mi sembra ovvio che i programmatori che utilizzano questi linguaggi utilizzino gli stessi schemi di progettazione disponibili per ogni altro OOP linguaggio. Infatti, in questo momento uso F # e OCaml ogni giorno, e non ci sono differenze sorprendenti tra i pattern che uso in queste lingue rispetto ai pattern che uso quando scrivo in Java.

C'è qualche verità nell'affermazione che la programmazione funzionale elimina la necessità di OOP schemi di progettazione? In tal caso, potresti postare o collegare ad un esempio di un tipico pattern OOP design e il suo equivalente funzionale?

1013
Juliet

Il post sul blog che hai citato esagera un po 'la sua affermazione. FP no elimina la necessità di schemi di progettazione. Il termine "schemi di progettazione" non è ampiamente utilizzato per descrivere la stessa cosa nelle lingue FP. Ma esistono. I linguaggi funzionali hanno molte delle migliori regole pratiche del modulo "quando incontri il problema X, usa un codice che assomiglia a Y", che è fondamentalmente ciò che è un modello di progettazione.

Tuttavia, è corretto che la maggior parte dei modelli di progettazione specifici per OOP siano praticamente irrilevanti nei linguaggi funzionali.

Non penso che dovrebbe essere particolarmente controverso affermare che i modelli di design in generale esistono solo per correggere le carenze nella lingua. E se un'altra lingua può risolvere banalmente lo stesso problema, quell'altra lingua non avrà bisogno di un modello di progettazione per questo. Gli utenti di quella lingua potrebbero non essere nemmeno consapevoli che il problema esiste , perché, beh, non è un problema in quella lingua.

Ecco cosa la Gang of Four ha da dire su questo problema:

La scelta del linguaggio di programmazione è importante perché influenza il punto di vista di una persona. I nostri modelli assumono le caratteristiche del linguaggio di livello Smalltalk/C++ e questa scelta determina cosa può e non può essere implementato facilmente. Se avessimo assunto linguaggi procedurali, avremmo potuto includere modelli di design chiamati "Inheritance", "Encapsulation" e "Polymorphism". Allo stesso modo, alcuni dei nostri pattern sono supportati direttamente dai linguaggi meno comuni orientati agli oggetti. CLOS ha multi-metodi, ad esempio, che riducono la necessità di un modello come Visitor. In effetti, ci sono abbastanza differenze tra Smalltalk e C++ per indicare che alcuni modelli possono essere espressi più facilmente in una lingua rispetto all'altra. (Vedi Iterator per esempio.)

(Quanto sopra è una citazione dal libro Introduzione ai modelli di disegni, pagina 4, paragrafo 3)

Le caratteristiche principali della programmazione funzionale includono funzioni come valori di prima classe, currying, valori immutabili, ecc. Non mi sembra ovvio che OO i modelli di progettazione stiano approssando una di quelle caratteristiche.

Qual è lo schema di comando, se non un'approssimazione delle funzioni di prima classe? :) In una lingua FP, devi semplicemente passare una funzione come argomento a un'altra funzione. In una lingua OOP, è necessario racchiudere la funzione in una classe, che è possibile creare un'istanza e quindi passare quell'oggetto all'altra funzione. L'effetto è lo stesso, ma in OOP si chiama uno schema di progettazione e richiede molto più codice. E qual è il modello astratto della fabbrica, se non sta funzionando? Passa i parametri a una funzione un po 'alla volta, per configurare il tipo di valore che sputa quando finalmente lo chiami.

Quindi sì, molti modelli di progettazione GoF sono resi ridondanti nelle lingue FP, perché esistono alternative più potenti e più facili da usare.

Ma naturalmente ci sono ancora schemi di progettazione che sono non risolti dalle lingue FP. Qual è l'equivalente FP di un singleton? (Trascurando per un momento che i singleton sono generalmente un modello terribile da usare)

E funziona anche in entrambe le direzioni. Come ho detto, FP ha anche i suoi schemi di progettazione, le persone semplicemente non li considerano come tali.

Ma potresti aver attraversato le monadi. Quali sono, se non un modello di progettazione per "trattare con lo stato globale"? Questo è un problema così semplice nelle lingue OOP che non esiste un modello di progettazione equivalente.

Non abbiamo bisogno di un modello di progettazione per "incrementare una variabile statica" o "leggere da quel socket", perché è proprio quello che tu fai .

Dire una Monade è un modello di design è altrettanto assurdo che dire gli Interi con le loro solite operazioni e l'elemento zero è un modello di progettazione. No, una Monade è un modello matematico , non un modello di progettazione.

Nei (puri) linguaggi funzionali, gli effetti collaterali e lo stato mutabile sono impossibili, a meno che non si lavori attorno a esso con il "modello di progettazione" monade, o con uno qualsiasi degli altri metodi per consentire la stessa cosa.

Inoltre, nei linguaggi funzionali che supportano OOP (come F # e OCaml), mi sembra ovvio che i programmatori che utilizzano questi linguaggi utilizzino gli stessi schemi di progettazione disponibili per ogni altra lingua OOP. Infatti, in questo momento uso F # e OCaml ogni giorno, e non ci sono differenze sorprendenti tra i pattern che uso in questi linguaggi rispetto ai pattern che uso quando scrivo in Java.

Forse perché stai ancora pensando in modo imperativo? Molte persone, dopo aver affrontato le lingue imperative per tutta la vita, hanno difficoltà a rinunciare a quell'abitudine quando cercano un linguaggio funzionale. (Ho visto alcuni tentativi piuttosto divertenti su F #, dove letteralmente ogni funzione era solo una stringa di istruzioni "let", praticamente come se avessi preso un programma C, e ha sostituito tutti i punti e virgola con "let" :) :))

Ma un'altra possibilità potrebbe essere che non ti sei reso conto che stai risolvendo i problemi banalmente, che richiederebbero schemi di progettazione in un linguaggio OOP.

Quando usi curriculum o passa una funzione come argomento a un altro, fermati e pensa a come lo faresti in una lingua OOP.

C'è qualche verità nell'affermazione che la programmazione funzionale elimina la necessità di schemi di progettazione OOP?

Sì. :) Quando lavori in un linguaggio FP, non hai più bisogno dei pattern di progettazione specifici per OOP. Ma hai ancora bisogno di alcuni schemi generali di progettazione, come MVC o altre cose specifiche non OOP, e invece hai bisogno di un paio di nuovi "modelli di progettazione" specifici per FP. Tutte le lingue hanno i loro difetti e gli schemi di progettazione sono solitamente il modo in cui lavoriamo intorno a loro.

Ad ogni modo, potresti trovare interessante provare le lingue "più pulite" FP, come ML (il mio preferito, almeno per scopi di apprendimento), o Haskell, dove non hai il OOP stampella per ricominciare quando ci si trova di fronte a qualcosa di nuovo.


Come previsto, alcune persone si sono opposte alla mia definizione di modelli di progettazione come "rattoppare le carenze in una lingua", quindi ecco la mia giustificazione: come già detto, la maggior parte dei modelli di progettazione sono specifici per un paradigma di programmazione o, talvolta, persino per una lingua specifica. Spesso risolvono problemi che solo esistono in quel paradigma (vedi monadi per FP, o fabbriche astratte per OOP). Perché il modello di fabbrica astratta non esiste in FP? Perché il problema che cerca di risolvere non esiste lì. Quindi, se esiste un problema nelle lingue OOP, che non esiste nelle lingue FP, allora chiaramente questo è un difetto delle lingue OOP. Il problema può essere risolto, ma il tuo linguaggio non lo fa, ma richiede un sacco di codice per iniziare a lavorarci intorno. Idealmente, vorremmo che il nostro linguaggio di programmazione rendesse magicamente tutti i problemi scomparsi. Qualsiasi problema che sia ancora presente è in linea di principio un difetto della lingua. ;)

1032
jalf

C'è qualche verità nell'affermazione che la programmazione funzionale elimina la necessità di schemi di progettazione OOP?

La programmazione funzionale non è la stessa della programmazione orientata agli oggetti. I modelli di progettazione orientati agli oggetti non si applicano alla programmazione funzionale. Invece, hai schemi di progettazione della programmazione funzionale.

Per la programmazione funzionale, non leggerete i libri di modelli di progettazione OO, leggerete altri libri sui modelli di progettazione FP.

linguaggio agnostico

Non totalmente Solo linguistica indipendente rispetto alle lingue OO. I modelli di progettazione non si applicano affatto ai linguaggi procedurali. Hanno appena senso in un contesto di progettazione di database relazionale. Non si applicano quando si progetta un foglio di calcolo.

un tipico modello di design OOP e il suo equivalente funzionale?

Quanto sopra non dovrebbe esistere. È come chiedere un pezzo di codice procedurale riscritto come codice OO. Ummm ... Se traduco il Fortran originale (o C) in Java, non ho fatto altro che tradurlo. Se lo riscrivo completamente in un paradigma OO, non assomiglierà più a Fortran o C originali, sarà irriconoscibile.

Non esiste una semplice mappatura da OO Design a Functional Design. Sono modi molto diversi di guardare al problema.

La programmazione funzionale (come tutti gli stili di programmazione della programmazione ha schemi di progettazione. I database relazionali hanno schemi di progettazione, OO ha schemi di progettazione, la programmazione procedurale ha schemi di progettazione. Tutto ha schemi di design, persino l'architettura degli edifici.

I modelli di progettazione - come concetto - sono un modo di costruire senza tempo, indipendentemente dalla tecnologia o dal dominio del problema. Tuttavia, schemi di progettazione specifici si applicano a domini e tecnologie specifici del problema.

Tutti quelli che pensano a quello che stanno facendo scopriranno modelli di design.

146
S.Lott

I commenti di Brian sullo stretto legame tra linguaggio e pattern sono al punto,

La parte mancante di questa discussione è il concetto di idioma. Il libro di Coplien, "Advanced C++" ha avuto un'enorme influenza qui. Molto prima che scoprisse Christopher Alexander e la Column Without a Name (e non si può parlare in modo ragionevole dei pattern senza leggere neanche Alexander), ha parlato del importanza di padroneggiare l'idioma nell'apprendimento di una lingua. Ha usato la copia stringa in C come esempio, mentre (* da ++ = * a ++); Puoi vedere questo come un bandaid per una caratteristica linguistica mancante (o una funzione di libreria), ma ciò che conta davvero è che è una più grande unità di pensiero, o di espressione, rispetto a qualsiasi sua parte.

Questo è ciò che i modelli e le lingue stanno cercando di fare, per permetterci di esprimere le nostre intenzioni in modo più sintetico. Più le unità di pensiero sono tanto più complesse sono i pensieri che puoi esprimere. Avere un vocabolario ricco e condiviso su una scala di scale - dall'architettura di sistema fino al piccolo bit - ci consente di avere conversazioni più intelligenti e pensieri su ciò che dovremmo fare.

Possiamo anche, come individui, imparare. Qual è l'intero punto dell'esercizio. Ognuno di noi può capire e usare cose che non saremmo mai in grado di pensare a noi stessi. Lingue, quadri, librerie, modelli, idiomi e così via hanno tutti il ​​loro posto nel condividere la ricchezza intellettuale.

44
grahamsw

Il libro GOF si lega esplicitamente a OOP - il titolo è Design Patterns - Elements of Reusable Object-Oriented Software (enfasi mia. )

38
bright

Design Patterns in Dynamic Programming di Peter Norvig ha una copertura ponderata di questo tema generale, sebbene su linguaggi 'dinamici' invece di 'funzionali' (c'è sovrapposizione).

33
Darius Bacon

Ecco un altro collegamento, discutendo questo argomento: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

Nel suo post sul blog, Edward descrive tutti e 23 i modelli GoF originali in termini di Haskell.

25
folone

Quando provi a guardare questo a livello di "modelli di progettazione" (in generale) e "FP contro OOP", le risposte che troverai saranno al massimo torbide.

Andate ad un livello più profondo su entrambi gli assi, però, e considerate specifici schemi di progettazione e caratteristiche linguistiche specifiche e le cose diventano più chiare.

Quindi, ad esempio, alcuni pattern specifici, come Visitor , Strategia , Comando , e L'Observer cambia o scompare definitivamente quando si usa una lingua con tipi di dati algebrici e pattern matching , chiusure , funzioni di prima classe , ecc. Alcuni altri modelli del libro di GoF rimangono comunque "aggirati".

In generale, direi che, nel tempo, i modelli specifici vengono eliminati dalle nuove funzionalità linguistiche (o semplicemente dalla crescente popolarità). Questo è il corso naturale del design del linguaggio; man mano che le lingue diventano più di alto livello, le astrazioni che in precedenza potevano essere chiamate in un libro solo con gli esempi ora diventano applicazioni di una particolare funzione linguistica o libreria.

(A parte: ecco un blog recente che ho scritto, che ha altri link a più discussioni su FP e modelli di design.)

19
Brian

La presentazione di Norvig allude a un'analisi che hanno fatto di tutti i pattern GoF, e affermano che 16 dei 23 pattern avevano implementazioni più semplici in linguaggi funzionali o erano semplicemente parte del linguaggio. Quindi presumibilmente almeno sette di loro erano a) ugualmente complicati o b) non presenti nella lingua. Sfortunatamente per noi, non sono elencati!

Penso che sia chiaro che la maggior parte dei modelli "creativi" o "strutturali" in GoF sono solo trucchi per ottenere i sistemi di tipo primitivi in ​​Java o C++ per fare ciò che vuoi. Ma il resto è degno di considerazione, indipendentemente dalla lingua in cui si programma.

Uno potrebbe essere il prototipo; mentre è una nozione fondamentale di JavaScript, deve essere implementata da zero in altre lingue.

Uno dei miei pattern preferiti è il pattern Null Object: rappresenta l'assenza di qualcosa come un oggetto che fa un tipo appropriato di nulla. Questo potrebbe essere più facile da modellare in un linguaggio funzionale. Tuttavia, il vero risultato è lo spostamento di prospettiva.

16

Direi che quando hai un linguaggio come LISP con il suo supporto per le macro, allora puoi costruire le tue astrazioni specifiche del dominio, astrazioni che spesso sono molto meglio delle solite soluzioni idiomatiche.

15

E anche le soluzioni OO Design Pattern sono specifiche per la lingua. I modelli di progettazione sono soluzioni a problemi comuni che il tuo linguaggio di programmazione non risolve per te. In Java, il modello Singleton risolve il problema one-of-something (semplificato). In Scala, hai un costrutto di livello superiore chiamato Oggetto oltre a Class. È pigramente istanziato e ce n'è solo uno. Non è necessario utilizzare il modello Singleton per ottenere un Singleton. Fa parte della lingua.

9
Dan Sickles

I pattern sono modi per risolvere problemi simili che vengono visti ancora e ancora, e quindi vengono descritti e documentati. Quindi no, FP non sostituirà i pattern; tuttavia, FP potrebbe creare nuovi pattern e rendere "obsoleti" alcuni modelli di "migliori pratiche" correnti.

8
Edwin Buck

Come altri hanno già detto, esistono schemi specifici di programmazione funzionale. Penso che il problema di eliminare gli schemi di progettazione non riguardi tanto il passaggio al funzionale, quanto una questione di caratteristiche del linguaggio .

Date un'occhiata a come Scala elimina il "modello singleton": dichiarate semplicemente un oggetto invece di una classe. Un'altra caratteristica, la corrispondenza dei modelli, aiuta a evitare il clunkiness del pattern del visitatore. Vedi il confronto qui: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

E Scala, come F #, è una fusione di OO-funzionale. Non conosco F # ma probabilmente ha questo tipo di funzionalità.

Le chiusure sono presenti in un linguaggio funzionale, ma non devono essere limitate a loro. Aiutano con lo schema del delegato.

Un'altra osservazione. Questo pezzo di codice implementa uno schema: è così classico ed è così elementare che di solito non lo consideriamo un "pattern", ma è sicuro che sia:

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

Linguaggi imperativi come Java e C # hanno adottato ciò che è essenzialmente un costrutto funzionale per affrontare questo: "foreach".

8
Germán

I pattern di progettazione GoF sono la codifica di ricette alternative per OO lingue discendenti di Simula 67, come Java e C++.

La maggior parte dei "mali" trattati dai modelli di progettazione sono causati da:

  • classi tipizzate staticamente, che specificano oggetti ma non sono essi stessi oggetti;
  • restrizione alla singola spedizione (solo l'argomento più a sinistra è usato per selezionare un metodo, gli argomenti rimanenti sono considerati solo come tipi statici: se hanno tipi dinamici, dipende dal metodo per risolverlo con approcci ad-hoc);
  • distinzione tra chiamate di funzioni regolari e chiamate di funzioni orientate agli oggetti, il che significa che le funzioni orientate agli oggetti non possono essere passate come argomenti funzionali in cui sono previste funzioni regolari e viceversa; e
  • distinzione tra "tipi di base" e "tipi di classe".

Non c'è uno solo di questi pattern di progettazione che non scompare nel Common LISP Object System, anche se la soluzione è strutturata essenzialmente nello stesso modo del modello di design corrispondente. (Inoltre, quel sistema di oggetti precede il libro GoF di oltre un decennio.Il Common LISP è diventato uno standard ANSI lo stesso anno in cui quel libro è stato pubblicato per la prima volta.)

Per quanto riguarda la programmazione funzionale, indipendentemente dal fatto che gli schemi si applichino o meno dipende dal fatto che il dato linguaggio di programmazione funzionale abbia qualche tipo di sistema di oggetti e se sia modellato sui sistemi oggetto che traggono beneficio dai modelli. Questo tipo di orientamento all'oggetto non si sposa bene con la programmazione funzionale, perché la mutazione dello stato è anteriore e centrale.

La costruzione e l'accesso non mutante sono compatibili con la programmazione funzionale, e quindi potrebbero essere applicabili schemi che hanno a che fare con l'astrazione dell'accesso o della costruzione: modelli come Fabbrica, Facciata, Proxy, Decoratore, Visitatore.

D'altra parte, i modelli comportamentali come State e Strategy probabilmente non direttamente si applicano in funzionale OOP perché la mutazione di stato è a il loro nucleo Questo non significa che non si applicano; forse in qualche modo si applicano in combinazione con qualsiasi trucco disponibile per simulare lo stato mutabile.

8
Kaz

Mi piacerebbe collegare un paio di carte eccellenti ma piuttosto dense di Jeremy Gibbons: "Modelli di design come programmi generici di tipo più alto ordine" e "L'essenza del pattern di Iterator" (entrambi disponibili qui: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Entrambi descrivono come i costrutti funzionali idiomatici coprano il terreno coperto da specifici schemi di progettazione in altre impostazioni (orientate agli oggetti).

7
sclv

Non puoi avere questa discussione senza far apparire i sistemi di tipi.

Le caratteristiche principali della programmazione funzionale includono funzioni come valori di prima classe, currying, valori immutabili, ecc. Non mi sembra ovvio che OO i modelli di progettazione stiano approssando una di quelle caratteristiche.

Questo perché queste funzionalità non affrontano gli stessi problemi che OOP fa ... sono alternative alla programmazione imperativa. La risposta FP a OOP si trova nei sistemi di tipi di ML e Haskell ... in particolare tipi di somma, tipi di dati astratti, moduli ML, tipecche Haskell.

Ma naturalmente ci sono ancora schemi di progettazione che non sono risolti dalle lingue FP. Qual è l'equivalente FP di un singleton? (Trascurando per un momento che i singleton sono generalmente un modello terribile da usare)

La prima cosa che fanno i typeclass è eliminare la necessità di singleton.

Potresti passare dalla lista dei 23 ed eliminare di più, ma non ho tempo per ora.

6
Jason Ganetsky

Penso che solo due modelli di GoF Design siano progettati per introdurre la logica di programmazione funzionale in un linguaggio naturale OO. Penso a Strategia e Comando. Alcuni degli altri modelli di design GoF possono essere modificati dalla programmazione funzionale per semplificare la progettazione e mantenere lo scopo.

4
CyaNnOrangeHead

In sostanza, !

  • Quando un pattern elude le caratteristiche mancanti (funzioni di ordine elevato, gestione dei flussi ...) che ultimalty facilita la composizione .
  • La necessità di riscrivere l'implementazione dei pattern ancora e ancora può essere vista come un odore di linguaggio .

Inoltre, questa pagina (AreDesignPatternsMissingLanguageFeatures) fornisce una tabella di traduzione "schema/funzionalità" e alcune discussioni di Nizza, se sei disposto a scavare.

4
YvesgereY

Gli schemi OOP e GoF riguardano gli stati. OOP modella la realtà per mantenere il codice base il più vicino possibile alle specifiche esigenze della realtà. I modelli di progettazione GoF sono modelli identificati per risolvere problemi atomici del mondo reale. Gestiscono il problema dello stato in modo semantico.

Come nella programmazione funzionale reale non esiste uno stato, non ha senso applicare i modelli GoF. Non ci sono schemi di progettazione funzionali nello stesso modo in cui esistono modelli di design GoF. Ogni modello di design funzionale è artificio in contrasto con la realtà in quanto le funzioni sono costrutti di matematica e non realtà.

Le funzioni mancano del concetto di tempo in quanto restituiscono sempre lo stesso valore indipendentemente dall'ora corrente, a meno che il tempo non sia parte dei parametri della funzione, cosa che rende davvero difficile elaborare "richieste future". Le lingue ibride mescolano questi concetti e rendono le lingue non linguaggi di programmazione funzionale reali.

I linguaggi funzionali stanno sorgendo solo per una cosa: le attuali restrizioni naturali della fisica. I processori di oggi sono limitati nella velocità delle istruzioni di elaborazione a causa delle leggi fisiche. Si vede una stagnazione nella frequenza di clock ma un'espansione nei core di elaborazione. Ecco perché il parallelismo delle istruzioni diventa sempre più importante per aumentare la velocità delle applicazioni moderne. Poiché la programmazione funzionale per definizione non ha stato e quindi non ha effetti collaterali, è sicuro elaborare le funzioni in sicurezza in parallelo.

I modelli GoF non sono obsoleti. Sono almeno necessari per modellare i requisiti del mondo reale. Ma se usi un linguaggio di programmazione funzionale devi trasformarli nei loro equivalenti ibridi. Finalmente non hai la possibilità di fare solo programmi funzionali se usi la persistenza. Per gli elementi ibridi del tuo programma rimane la necessità di utilizzare i modelli GoF. Qualsiasi altro elemento puramente funzionale non è necessario per utilizzare i modelli GoF perché non esiste uno stato.

Poiché il pattern GoF non è necessario per la programmazione funzionale reale, ciò non significa che i principi SOLID non dovrebbero essere applicati. I principi SOLID sono al di là di ogni paradigma linguistico.

3
oopexpert

Nella Programmazione funzionale, gli schemi di progettazione hanno un significato diverso, infatti, la maggior parte dei OOP schemi di progettazione non sono necessari nella programmazione funzionale a causa del livello più elevato di astrazione e HOF usati come blocchi di costruzione.

Il principio di un HOF significa che le funzioni possono essere passate come argomenti ad altre funzioni. e le funzioni possono restituire valori.

2
Ali Bayat

Nel nuovo libro del 2013 intitolato "Modelli di programmazione funzionale - in Scala e Clojure" l'autore Michael.B. Linn fa un lavoro decente confrontando e fornendo sostituzioni in molti casi per i modelli GoF e discute anche i nuovi modelli funzionali come "ricorsione della coda", "memoizzazione", "sequenza pigra", ecc.

Questo libro è disponibile su Amazon. L'ho trovato molto istruttivo e incoraggiante quando proveniva da uno sfondo OO di un paio di decenni.

2
manish

La programmazione funzionale non sostituisce i modelli di progettazione. I modelli di design non possono essere sostituiti.

I modelli esistono semplicemente; sono emersi nel tempo. Il libro GoF ha formalizzato alcuni di essi. Se nuovi modelli stanno venendo alla luce, gli sviluppatori usano linguaggi di programmazione funzionali che sono cose eccitanti, e forse ci saranno anche libri scritti su di loro.

2
ktingle

Penso che ogni paradigma abbia uno scopo diverso e in quanto tale non può essere paragonato in questo modo.

Non ho sentito che gli schemi di progettazione GoF sono applicabili a tutte le lingue. Ho sentito che sono applicabili a tutti i linguaggi OOP . Se si utilizza la programmazione funzionale, il dominio dei problemi risolti è diverso da OO lingue.

Non userei il linguaggio funzionale per scrivere un'interfaccia utente, ma uno dei linguaggi OO come C # o Java renderebbe questo lavoro più semplice. Se scrivessi un linguaggio funzionale, non prenderei in considerazione l'uso di OO Design Patterns.

1

OOP e FP hanno obiettivi diversi, OOP ha lo scopo di incapsulare le complessità/parti mobili dei componenti software e FP mira a ridurre al minimo la complessità e le dipendenze dei componenti software questi 2 paradigmi non sono necessariamente contraddittori al 100% e potrebbero essere applicati insieme per ottenere il beneficio da entrambi i mondi. Anche con un linguaggio che non supporta nativamente la programmazione funzionale come C #, potresti scrivere codice funzionale se capisci i principi FP, allo stesso modo potresti applicare OOP principi usando F # se capisci OOP principi, modelli e migliori pratiche. Faresti la scelta giusta in base alla situazione e al problema che cerchi di risolvere, indipendentemente dal linguaggio di programmazione che usi.

1
Dogu Arslan

Come ha affermato la risposta accettata, OOP e FP hanno tutti i loro modelli specifici.

Tuttavia, ci sono alcuni modelli che sono così comuni che dovrebbero avere tutte le piattaforme di programmazione che posso pensare. Ecco una lista (incompleta):

  • Adattatore. Riesco a malapena a pensare a un'utile piattaforma di programmazione così completa (e auto-realizzata) che non ha bisogno di parlare al mondo. Se lo farà, è sicuramente necessario un adattatore.

  • Facciata. Qualsiasi piattaforma di programmazione in grado di gestire un grande codice sorgente dovrebbe essere in grado di modularizzare. Se dovessi creare un modulo per altre parti del programma, vorrai nascondere le parti "sporche" del codice e dargli un'interfaccia piacevole.

  • Interprete. In generale, qualsiasi programma sta facendo solo due cose: input di analisi e output di stampa. Gli input del mouse devono essere analizzati e i widget delle finestre devono essere stampati. Pertanto, avere un interprete incorporato dà al programma un ulteriore potere di personalizzare le cose.

Inoltre, ho notato in un tipico linguaggio FP, Haskell, c'è qualcosa di simile ai pattern GoF, ma con nomi diversi. Secondo me questo suggeriva che erano lì perché ci sono alcuni problemi comuni da risolvere in entrambi i linguaggi FP e OOP.

  • Trasformatore e decoratore Monad. Il primo aveva l'abitudine di aggiungere un'abilità aggiuntiva a una monade esistente, quest'ultima aggiunge un'abilità aggiuntiva a un oggetto esistente.
0
Earth Engine