Domanda

Ho familiarità con l'architettura orientata agli oggetti, compreso l'uso di modelli di progettazione e diagrammi di classi per la visualizzazione, e conosco l'architettura orientata ai servizi con i suoi contratti e collegamenti di protocollo, ma c'è qualcosa di caratteristico nell'architettura software di un sistema scritto in un linguaggio di programmazione funzionale?

So che la FP è stata utilizzata per progetti di medie e grandi dimensioni.Paul Graham ha scritto la prima incarnazione di Yahoo!Memorizzare in Common Lisp.Alcuni sistemi di sviluppo lisp sono complessi.L’intelligenza artificiale e i sistemi finanziari scritti in linguaggi funzionali possono diventare piuttosto grandi.Hanno tutti almeno una sorta di architettura intrinseca, però, mi chiedo se hanno qualcosa in comune?

Come si presenta un'architettura basata sulla valutazione delle espressioni?Le architetture FP sono più componibili?

Aggiornamento: Kyle me lo ha ricordato SICP è una buona risorsa per questo argomento.

Aggiornamento 2: Ho trovato un buon post sull'argomento: In che modo la programmazione funzionale influisce sulla struttura del codice?

È stato utile?

Soluzione

Il filo conduttore nell'"architettura" dei progetti che utilizzano linguaggi funzionali è che essi tendono a essere separati in strati di algebre piuttosto che in sottosistemi nel senso tradizionale dell'architettura dei sistemi.

Per ottimi esempi di tali progetti, dai un'occhiata XMonade, , E HappS.Se esaminate come sono strutturati, scoprirete che comprendono strati di struttura monadica con qualche collante combinatore in mezzo.

Guarda anche L'esperimento della Scala documento che delinea un'architettura in cui un sistema è composto da componenti che astraggono dalle loro dipendenze.

Altri suggerimenti

Attualmente sto lavorando al libro "Design e Architettura nella Programmazione Funzionale".Descrive molti modelli e approcci di progettazione che esistono nel puro mondo FP (il linguaggio principale è Haskell), ma non solo.Il libro ti insegna come costruire da zero grandi applicazioni con stato puro e impuro, multithreading, rete, database, GUI, come dividerle in livelli e ottenere semplicità.Mostra anche come modellare domini e linguaggi, come organizzare e descrivere l'architettura dell'applicazione, come testarla e altro ancora.

L'elenco degli argomenti include:

  • Approcci alla modellazione dell'architettura utilizzando diagrammi;
  • Analisi dei requisiti;
  • Modellazione di domini DSL incorporati;
  • Progettazione e implementazione DSL esterna;
  • Monadi come sottosistemi con effetti;
  • Monadi libere come interfacce funzionali;
  • eDSL frecciate;
  • Inversione del controllo tramite eDSL monadici gratuiti;
  • Memoria transazionale del software;
  • Lenti a contatto;
  • Monadi Stato, Lettore, Scrittore, RWS, ST;
  • Stato impuro:IORef, MVar, STM;
  • Multithreading e modellazione di domini concorrenti;
  • GUI;
  • Applicabilità di tecniche e approcci tradizionali come UML, SOLID, GRASP;
  • Interazione con sottosistemi impuri.

Il libro è basato sui progetti Haskell su cui sto effettuando ricerche, in particolare su un'applicazione SCADA Andromeda.Il codice per questo libro è disponibile Qui.Mentre il libro è in fase di sviluppo (lo farà fino alla fine del 2017), posso consigliarti di familiarizzare con il mio articolo "Design e Architettura in FP" Qui (Russo).

AGGIORNAMENTO

Ho condiviso il mio libro online (primi 5 capitoli). Vedi il post su Reddit

La più grande comunanza che troverai nei linguaggi funzionali è l'uso delle funzioni per archiviare i dati.È un po' come usare le funzioni di accesso su un oggetto senza l'oggetto.La funzione viene invece creata in un ambiente in cui ha accesso ai dati di cui ha bisogno.Ora questa funzione può essere passata e utilizzata ovunque mantenendo comunque la possibilità di utilizzare i dati.

Ecco un esempio molto semplice.Questo non è puramente funzionale in quanto cambia stato, ma è abbastanza comune:

(define (make-counter)
  (let ((count 0))
    (lambda ()
      (set! count (+ count 1))
      count)))

(define x (make-counter))

(x) returns 1

(x) returns 2

...etc...

Quindi abbiamo una funzione, make-counter, che restituisce un'altra funzione che ha al suo interno lo stato del contatore.Possiamo chiamare il contatore appena creato e osservare il cambiamento al suo interno.

Ecco come sono strutturati i programmi funzionali.Hai funzioni che accettano funzioni come argomenti, hai funzioni che restituiscono funzioni con stato nascosto, ecc.È tutto molto più pulito che gestire la memoria da soli.

Ho lavorato con alcuni progetti funzionali abbastanza grandi.Di solito rientrano in due campi (almeno quelli che ho usato):

  • Estrema scalabilità/affidabilità/concorrenza.I modelli transazionali possono essere integrati molto strettamente nel linguaggio.Il Concurrent ML ne è un ottimo esempio e i progetti che lo utilizzano sono molto difficili da sbagliare quando si tratta di correttezza della concorrenza.
  • Analisi/modifica dei framework.Molti dei modelli di progettazione su cui si basano questi framework sono incredibilmente facili da formulare/costruire/modificare in linguaggi funzionali.Il modello dei visitatori ne è un ottimo esempio.

Ho stampato e dato un'occhiata Modelli di progettazione in Ocaml, e utilizzano moduli e funtori (e oggetti) per ricreare i normali modelli di progettazione a cui siamo abituati.È interessante, ma penso che usino oggetti pure molto per vedere davvero il vantaggio dei linguaggi funzionali.FP è molto componibile, fa parte della sua natura.Immagino che la mia risposta breve sia usare moduli E funtori.

Il mio progetto attuale è piuttosto grande e separiamo ogni modulo per file --impliciti in ocaml.Ho anche cercato una risorsa completa che potesse contenere alcuni punti di vista alternativi o alcune riflessioni su un design di grande successo che è emerso da un progetto.

Speriamo che non sia troppo tangenziale, ma probabilmente interessante per chiunque cerchi le risposte a questa domanda è questa presentazione Modelli di progettazione nella programmazione dinamica di Peter Norvig.

Penso che questo possa aiutare;

Alcuni dei modelli scompaiono - cioè sono supportati direttamente dalle caratteristiche del linguaggio, alcuni schemi sono più semplici o hanno una messa a fuoco diversa e alcuni sono essenzialmente invariati.

[AIM-2002-005] Gregory T.Sullivan, Funzionalità avanzate del linguaggio di programmazione per modelli di progettazione eseguibili "Modelli migliori attraverso la riflessione

22 marzo 2002

Il libro dei modelli di progettazione [GOF95] presenta 24 modelli testati nel tempo che appaiono costantemente in sistemi software ben progettati.Ogni modello è presentato con una descrizione del problema di progettazione che gli indirizzi del modello, nonché il codice di implementazione del campione e le considerazioni di progettazione.Questo documento esplora come i modelli del libro "Gang of Four '' o" GOF ", come viene spesso chiamato, appaiono quando problemi simili vengono affrontati usando un linguaggio di programmazione dinamico, di ordine superiore, orientato agli oggetti.Alcuni dei modelli scompaiono - cioè sono supportati direttamente dalle caratteristiche del linguaggio, alcuni schemi sono più semplici o hanno una messa a fuoco diversa e alcuni sono essenzialmente invariati.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top