Progettazione in linguaggi "misti": progettazione orientata agli oggetti o programmazione funzionale?

Negli ultimi anni, le lingue che mi piace usare stanno diventando sempre più "funzionali". Ora uso linguaggi che sono una sorta di "ibrido": C #, F #, Scala. Mi piace progettare la mia applicazione usando classi che corrispondono agli oggetti di dominio e utilizzare funzionalità funzionali che rendono la codifica più semplice, più coincidente e più sicura (specialmente quando si opera su raccolte o quando si passano funzioni).

Tuttavia i due mondi si "scontrano" quando si tratta di progettare modelli. L'esempio specifico che ho affrontato di recente è il modello Observer. Voglio che un produttore notifichi un altro codice (i "consumatori / osservatori", diciamo un archivio DB, un logger e così via) quando un oggetto viene creato o modificato.

Inizialmente l'ho fatto "funzionalmente" in questo modo:

producer.foo(item => { updateItemInDb(item); insertLog(item) })
// calls the function passed as argument as an item is processed

Ma ora mi chiedo se dovrei usare un approccio più "OO":

interface IItemObserver {
  onNotify(Item)
}
class DBObserver : IItemObserver ...
class LogObserver: IItemObserver ...

producer.addObserver(new DBObserver)
producer.addObserver(new LogObserver)
producer.foo() //calls observer in a loop

Quali sono i pro e i contro dei due approcci? Una volta ho sentito un guru del FP dire che i modelli di progettazione esistono solo a causa delle limitazioni del linguaggio, ed è per questo che ci sono così pochi nei linguaggi funzionali. Forse questo potrebbe esserne un esempio?

EDIT: Nel mio scenario particolare non ne ho bisogno, ma .. come implementeresti la rimozione e l'aggiunta di "osservatori" in modo funzionale? (Vale a dire come implementereste tutte le funzionalità nel modello?) Passando ad una nuova funzione, per esempio?

Questo è un buon esempio di due diversi approcci che portano l'idea di eseguire un'attività al di fuori del limite di preoccupazione per l'oggetto chiamante.

Mentre in questo esempio è chiaro che dovresti optare per l'approccio funzionale, in generale dipenderà davvero dalla complessità del comportamento che l'oggetto chiamato deve esibire. Se si tratta davvero di un comportamento complesso, in cui ti ritroverai a riapplicare spesso una logica simile e i generatori di funzioni non possono essere utilizzati per esprimerla chiaramente, allora probabilmente vorrai andare per composizione di classe o eredità, dove hanno un po 'più di libertà di riutilizzo ed estensione del comportamento esistente su una base ad hoc.

Uno schema che ho osservato, tuttavia, è che di solito gli sviluppatori scelgono inizialmente un approccio funzionale e solo una volta che si presenta la domanda di un comportamento più granulare, decidono di adottare un approccio di classe. So, ad esempio, che Django è passato da viste basate su funzioni, caricatori di modelli e test runner a quelli basati su classi una volta che i vantaggi e i requisiti sono diventati ovvi, ma non prima.

La versione funzionale è molto più breve, più facile da mantenere, più facile da leggere e, in generale, notevolmente superiore in quasi ogni aspetto immaginabile.

Molti-sebbene, lontano dal all- modelli sono per compensare la mancanza di caratteristiche in OOP, come osservatori. Questi sono molto meglio modellati funzionalmente.

Il tuo "FP guru" ha in parte ragione; molti modelli OO sono hack per fare cose funzionali. (La sua affermazione che questa è la ragione per cui pochi linguaggi FP sembrano al meglio discutibili.) I modelli Observer e Strategia stanno cercando di emulare funzioni di prima classe. Il modello visitatore è un trucco per simulare la corrispondenza dei modelli. La tua IItemObserverè solo una funzione mascherata. Fingere che sia diverso da qualsiasi altra funzione che accetta un oggetto non ti compra nulla.

Gli oggetti sono solo un tipo di astrazione dei dati. Questo documento aiuterà a far luce su questo argomento. Gli oggetti possono essere utili, ma è importante riconoscere che non sono adatti a tutto. Non c'è dicotomia; semplicemente questione di scegliere lo strumento giusto per il lavoro giusto e la programmazione funzionale non richiede in alcun modo di rinunciare agli oggetti. A parte questo, la programmazione funzionale è molto più che usare semplicemente le funzioni. Si tratta anche di ridurre al minimo gli effetti collaterali e la mutazione.

Non posso davvero rispondere alla domanda perché non sono bravo nei linguaggi funzionali; ma penso che dovresti essere meno preoccupato dell'approccio fintanto che ciò che hai funziona. Da quello che ho capito, purché non si aggiungano più ascoltatori in futuro o non si cambino gli ascoltatori durante l'esecuzione, è possibile saltare qui il modello di Observer.

Non sono d'accordo sul fatto che i modelli di progettazione compensino le "limitazioni" nei linguaggi OO. Sono lì per fare buon uso delle funzionalità OOP. Il polimorfismo e l'ereditarietà sono caratteristiche, non limitazioni. I modelli di progettazione fanno uso di queste funzionalità per promuovere un design flessibile. Puoi creare un programma assolutamente non OO in un OO. Puoi, con molta cura, scrivere un intero programma contenente oggetti che non hanno stato, imitando FP.