Come decidi dove la funzionalità dovrebbe appartenere a un progetto su larga scala?

Scegliere tra una libreria e un file eseguibile è relativamente semplice: ha senso eseguire il codice che si desidera inserire in un eseguibile come programma autonomo? In caso contrario, dovrebbe probabilmente essere una libreria. In generale, preferirei un sottile livello eseguibile su tutte le librerie necessarie, dal momento che è più facile riutilizzare quelle back-end e non sono legate a un particolare programma.

A parte decidere come dividere il codice tra le librerie, potresti trovare l'articolo sulla granularità di Uncle Bob Martin utile.

In esso parla della struttura OO e definisce diversi principi che possono aiutarti a impacchettare il tuo codice in modo appropriato. Questi sono anche trattati in modo più dettagliato nel suo libro, Principi, modelli e pratiche agili in C # .

Riassumerò i seguenti principi:

Reuse / Release Equivalence Principle (REP)

The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.

Zio Bob definisce il riutilizzo come in grado di collegare staticamente o dinamicamente la libreria riutilizzata nel suo programma e di non dover mai guardare il suo codice sorgente. Quando viene rilasciata una nuova versione della libreria, può semplicemente integrarla nel suo sistema.

Trattando le librerie in questo modo si guida solo mantenendo le cose correlate insieme nello stesso pacchetto. Altrimenti, i consumatori della biblioteca potrebbero dover eseguire l'aggiornamento a una nuova versione senza motivo o ritardare alcune versioni precedenti.

Common Reuse Principle (CRP)

The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

Questo principio supporta quello sopra. Se hai classi nello stesso pacchetto che non sono correlate tra loro, potresti costringere gli utenti della tua biblioteca a effettuare l'upgrade inutilmente.

Common Closure Principle (CCP)

The classes in a package should be closed against the same kinds of changes. A change that affects a package affects all the classes in that package.

Questo principio parla della manutenibilità. L'idea qui è di raggruppare le classi in base a come potrebbero aver bisogno di cambiare. In questo modo le tue modifiche possono essere localizzate in una parte dell'applicazione e non diffuse dappertutto.

Il principio delle dipendenze acicliche (ACP)

The dependency structure between packages must be a Directed Acyclic Graph (DAG). That is, there must be no cycles in the dependency structure.

L'annullamento delle dipendenze cicliche consente a ogni pacchetto di essere sviluppato indipendentemente e "rilasciato" al resto dell'azienda quando sono pronti nuovi cambiamenti. In questo modo non ti ritroverai con due squadre in stallo, in attesa l'una dell'altra per finire il lavoro.

Che cosa renderà più semplice mantenere il codice a lungo termine? Se si hanno funzioni non correlate nello stesso componente (vale a dire, dll, exe, unità compilata), e si deve cambiare una funzione, è quella che va a rompere l'altra? Quando apporti una modifica a un componente, dovrai ripetere il test di tutti i componenti downstream in base a TUTTE le funzioni di quel componente. Se limiti la funzionalità all'interno di ciascun componente, la modifica di ciascuno sarà meno rischiosa.

Inoltre, concentrando i componenti su un numero limitato di funzionalità strettamente correlate, avrai un tempo molto più semplice per dimostrare che quel componente si comporta come dovrebbe.

Un modo semplice per approcciare una risposta è riconoscere che "DLL" sta per "biblioteca a collegamento dinamico" e il termine chiave è "libreria".

Che cosa vuoi in una normale libreria? Buoni libri che saranno condivisi da molti lettori (utenti); oggetti utili che raccolgono polvere fino a quando un lettore (utente) fa riferimento a una domanda critica in un momento forse disperato; e risorse che collegano i lettori (utenti) ad altre risorse. Le librerie di codice sono simili. Manteniamo tali elementi come codice frequentemente condiviso, moduli di riferimento specializzati o di alto valore e le risorse della struttura architettonica in essi. Le librerie software possono essere rappresentate in diversi tipi di artefatti del codice, come script, librerie statiche, librerie dinamiche, componenti e file di risorse.

In generale, ti consiglio di fare in modo che i tuoi moduli eseguibili agiscano in qualche modo come gli script. Evidenziano e gestiscono chiaramente la struttura principale e il flusso del sistema, ma invocano risorse dalle tue librerie per gestire i dettagli nitidi. Trovo che questo approccio sia migliore di confondere la logica di alto livello con preoccupazioni di implementazione a basso livello confuse e eccessivamente specializzate e tecniche.

Quando si considera come allocare il codice tra eseguibili e librerie, è necessario considerare sia la progettazione logica che la progettazione fisica.

Nei sistemi orientati agli oggetti, ad esempio, è importante organizzare logicamente il codice per assegnare correttamente le responsabilità ai metodi corretti nelle classi corrette. Questo fa parte della progettazione della soluzione logica. Il tuo progetto logico dovrebbe essere chiaro, pulito e snello e dovrebbe essere espresso in termini terminologici che si riferiscono bene al dominio dei tuoi utenti.

Quando pianifichi di installare effettivamente il tuo sistema sul sito di un utente, potresti essere preoccupato di creare un progetto fisico che specifichi come associare il tuo codice in un insieme di oggetti di risorse software facilmente implementabili (di solito file) che possono essere prontamente mescolato e abbinato alle esigenze di un particolare sistema di destinazione. Determinare quali risorse appartengono al pacchetto di distribuzione in generale può comportare alcune considerazioni di progettazione fisica specifiche che non hanno nulla a che fare direttamente con la progettazione logica. Ad esempio, è possibile che si desideri scambiare determinate librerie di elaborazione dei file di immagine a seconda di quale cliente riceverà un determinato set di oggetti di distribuzione.

In pratica, scoprirai che un buon disegno logico di solito porta a un buon design fisico.

Per riassumere, il principio più importante è l'imballaggio intelligente. Organizzando i tuoi materiali di codice in librerie strongmente correlate, ti ritroverai con utili artefatti di codice utilizzabili che puoi facilmente riutilizzare, spostare o regalare.