Le architetture plugin sono un problema abbastanza noto in Object-Oriented Design, in cui di solito viene affrontato definendo un insieme di interfacce che il programma host si aspetta che i plug-in implementino.
Su .NET, il Managed Extensibility Framework è stato appositamente progettato per risolvere questo problema. Non solo supporta interfacce definite in anticipo dal programma host, ma può anche rilevare e comporre le interfacce richieste da un plug-in ( importa ) e implementare un altro plug-in ( esportazioni ).
Altri contenitori DI DI maturi che supportano Auto-registration basata su convenzione possono essere configurati per fornire le stesse funzionalità.
In F #, la sostituibilità e la composizione sono generalmente ottenute con funzioni anziché interfacce, ma non sono a conoscenza di alcun contenitore DI o altri componenti di composizione che funzionano su funzioni F # invece che su interfacce .NET. Dato che in questi giorni preferisco principalmente Pure DI , spero anche di non vederlo accadere.
Potresti chiederti perché questo è rilevante in un contesto F #, ma una volta che ti rendi conto che c'è un strong relazione tra oggetti e chiusure , la rilevanza potrebbe diventare più evidente.
In ogni caso, l'architettura suggerita qui non è come le architetture di plugin sono normalmente implementate. Come spiegato sopra, le architetture di plug-in vengono generalmente definite attorno a un insieme di comportamenti predefiniti , anziché a dati. Le interfacce ben progettate definiscono i comportamenti, proprio come le funzioni. Questi sono strongmente tipizzati e sostituibili (polimorfici).
È probabile che nel tempo i dati deboli tipizzati diventino un problema di manutenzione, quindi non andrei con quel progetto.
Puoi leggere ulteriori informazioni sulle architetture liberamente accoppiate (Object-Oriented) in il mio libro .
Non scrivi la tua causa principale per scrivere un'applicazione con un'architettura plug-in, ma a meno che tu non stia scrivendo una grande applicazione con involti termoretraibili come Visual Studio, un browser, un server web per scopi generici, o simili, questo tipo di architettura è molto probabilmente eccessivo .
Una delle migliori caratteristiche di F # è quella proibisce i cicli . Nei linguaggi orientati agli oggetti come C # e Java, le persone spesso utilizzano architetture basate su componenti come Porte e adattatori, architettura Onion, livelli, ecc. perché a livello di modulo, i cicli vengono prevenuti (non è possibile creare facilmente cicli con dipendenze rigide). Tuttavia, in F #, ottieni questa assistenza dal linguaggio stesso, quindi ci sono molte meno ragioni per affrontare l'accoppiamento con l'architettura; l'accoppiamento è già stato risolto dalla lingua .