Divisione di un singolo progetto in librerie

hmmm ...

Ci sono davvero due concetti in gioco qui ...

C'è una libreria dinamica contro statica , che è la principale domanda cui ti sei indirizzato. In questo caso, cosa dice Neil e quale è stata la risposta a cui si è riferito è che nella maggior parte delle implementazioni che utilizzano librerie dinamiche l'overhead extra non vale la pena. Rendere le librerie caricabili dinamicamente dalla tua applicazione spesso richiedono alcune considerazioni aggiuntive sul tuo codice e su come distribuisci la tua applicazione, che, a meno che tu non abbia davvero bisogno della funzionalità, spesso le volte rendono la tua app più complessa piuttosto che meno.

Ora, è vero che le librerie dinamiche sono fastidiose e dovrebbero essere usate con parsimonia non significa che dovresti astenervi dal creare librerie ... al contrario, dividere il tuo codice in più quasi indipendenti i moduli sono solo una buona pratica, renderà il tuo sistema complessivamente più facile da testare e mantenere.

Si noti che su alcune piattaforme i concetti di librerie dinamiche e statiche dipendono in buona misura dalla piattaforma e dal linguaggio che si sta utilizzando. Ad esempio in Java, tutte le librerie sono su un piano di parità. Immagino che sarebbe un po 'tra dinamico e statico dove è possibile cambiare le librerie senza dover ricompilare ciò che le usa, ma la gestione di moduli caricabili e scaricabili dinamicamente richiede un lavoro extra da eseguire correttamente per qualcosa di più dei casi d'uso più semplici. / p>

Nella maggior parte degli ambienti ho visto che supporta naturalmente le librerie dinamiche o se si desidera avere librerie dinamiche è necessario specificarlo esplicitamente.

Quindi in breve SÌ modularizza i tuoi sistemi e cerca di ridurre le interdipendenze tra la tua libreria, ad esempio non dovrebbero esserci cicli quando crei un grafico su come i tuoi moduli si interconnettono. (A- > B- > C- > A) Se succedono queste cose, allora la tua separazione non è del tutto giusta, se sembra semplicemente impossibile sbarazzarsi di un ciclo, forse il tuo non era destinato a essere separato nel primo luogo, o forse la tua modellazione dell'oggetto del tuo problema è carente.

Si noti tuttavia che la modularizzazione non elimina completamente la complessità, parte della quale viene trasferita alla gestione delle interdipendenze, delle versioni ecc.

Spero che questo aiuti.

Vorrei chiedere "perché le librerie condivise ?" Le librerie collegate staticamente sono molto più facili da utilizzare. Se non hai bisogno delle funzionalità "collegabili" del caricamento dinamico delle funzioni, allora dovrei sempre cercare le librerie statiche. Per quanto riguarda la tua situazione particolare, non penso che tu abbia fornito sufficienti informazioni per permetterci di consigliarti.

link

A mio parere, sì, dovresti modulare il tuo codice se lo riutilizzerai o meno per qualcos'altro. Dovresti farlo perché è una delle poche cose che puoi fare per prepararti meglio per il futuro, qualunque cosa assomigli. Mentre puoi provare a sovraesignare per assicurarti che il tuo codice possa rispondere a qualsiasi cambiamento, ti mancherà sempre qualcosa. Il codice modulare ti consente di estrarre pezzi che semplicemente non corrispondono più a quello che stai cercando di realizzare più.

Assicurarsi di lavorare in moduli discreti riduce anche l'opportunità e quindi l'invasione dell'accoppiamento imprevisto / indesiderato. Dovendo essere in grado di compilare un modulo da solo si evidenziano davvero le dipendenze che ha e limitando quelle che migliorano il design in modo tale che applicare le modifiche a un'area non incide magicamente su qualche parte remota del programma .... riduce comunque quel tipo di cose .

Migliora anche i tempi di compilazione. Se crei solo ciò di cui hai bisogno e lavori con le librerie e ne hai solo modificato uno o due ... allora è tutto quello che devi compilare.

Ho riscontrato che l'aderenza al Test unitario e al TDD è un modo migliore per applicare la modularità corretta senza sovrascrivere funzionalità che non possono mai essere utilizzate (ad esempio, creando librerie che non vengono mai riutilizzate). Per fare bene il test unitario, avrai bisogno di interfacce definite chiaramente e di classi piccole e con un solo scopo. Praticamente la stessa cosa che fai per una libreria ben definita.