Ho un piccolo problema con i termini modulo e componente. Nella mia mente, un modulo sono classi raggruppate, che sono accessibili solo tramite un'interfaccia ben definita. Nascondono tutti i dettagli di implementazione e sono riutilizzabili. I moduli definiscono i moduli da cui dipendono.
Qual è la differenza tra i componenti? Ho cercato in alcuni libri, ma la descrizione dei componenti è molto simile.
I termini sono simili. In generale, penso che un "modulo" sia più grande di un "componente". Un componente è una singola parte, di solito di portata relativamente piccola, probabilmente di uso generale. Esempi includono controlli dell'interfaccia utente e "componenti di sfondo" come timer, assistenti di threading ecc. Un "modulo" è un pezzo più grande del tutto, di solito qualcosa che esegue una funzione primaria complessa senza interferenze esterne. Potrebbe essere la libreria di classi di un'applicazione che fornisce integrazione con e-mail o database. Può essere grande quanto una singola applicazione di una suite, come il "Modulo Contabilità clienti" di una piattaforma ERP / contabilità.
Penso anche che i "moduli" siano più intercambiabili. I componenti possono essere replicati, con quelli nuovi che sembrano vecchi ma che sono "migliori" in qualche modo, ma in genere il design del sistema dipende più strettamente da un componente (o da una sostituzione progettata per conformarsi al comportamento molto specifico di quel componente). In termini non informatici, un "componente" può essere il blocco motore di un'automobile; puoi armeggiare all'interno del motore, anche sostituirlo del tutto, ma l'auto deve avere un motore, e deve conformarsi a specifiche molto rigide come dimensioni, peso, punti di fissaggio, ecc. per sostituire il motore "stock" che l'auto è stato originariamente progettato per avere. Un "modulo", d'altra parte, implica la funzionalità di tipo "plug-in"; qualunque sia il modulo, può essere comunicato in modo così leggero che il modulo può essere rimosso e / o sostituito con effetti minimi su altre parti del sistema. L'impianto elettrico di una casa è altamente modulare; puoi collegare qualsiasi cosa con una spina 120V15A in qualsiasi presa 120V15A e aspettarti che la cosa che stai collegando funzioni. Il cablaggio della casa non può fare a meno di ciò che è collegato, a condizione che le richieste di potenza in ogni singolo ramo del sistema non superino i limiti di sicurezza.
Il significato generico di modulo è un gruppo di codice riutilizzabile, non legato a un programma specifico. Questo potrebbe essere tutto da un intero set di librerie GUI fino a una singola classe.
Il significato generico di componente è un modulo con la restrizione aggiuntiva di sostituibilità utilizzando un'interfaccia specifica. Se si crea un componente GUI Widget, può essere utilizzato ovunque sia previsto un Widget, senza dover fare nulla di speciale nel codice chiamante. I moduli in generale non hanno tale restrizione. Qt e GTK + sono moduli, ma non posso scambiarli uno per l'altro senza un notevole lavoro nel codice che lo chiama, quindi non sono componenti.
Molti framework o linguaggi di programmazione usano i termini per indicare qualcosa di molto più specifico, motivo per cui le persone chiedono informazioni sul contesto. Qualcosa può essere un componente in senso generico, ma se non implementa un'interfaccia IComponent molto specifica, potrebbe non essere considerato un componente nel contesto. In python, module ha il significato tecnico molto specifico di qualcosa che puoi ottenere usando un comando import . Di solito le persone si riferiscono a questi significati specifici del contesto.
Se vogliamo astrarre da particolari linguaggi, framework e loro interpretazioni, la gerarchia della granularità del software astratto è la seguente:
Product - application, library, service
Module - GUI, core logic, data, etc...
Component - purpose specific collection of objects
Object - collection of primitives
Primitive - numbers, functions, etc...
Semplice e semplice, il prodotto è una raccolta funzionante di moduli funzionali.
Come suggerisce il nome stesso, la motivazione di un modulo è la modularità. Contrariamente a quanto sostengono molti, non implica realmente il riutilizzo del codice. Ci sono molti moduli che non sono veramente riutilizzabili e non si adattano a qualcosa a cui non sono stati progettati.
È importante separare i diversi livelli del software, il che rende il software molto più facile da implementare e mantenere, e se si ha la necessità di reimplementare qualcosa come un front-end in un diverso framework GUI, la modularità consente che ciò avvenga in modo facile e sicuro , senza infrangere il codice dappertutto.
Un modulo incapsula una raccolta di componenti che hanno tutti uno scopo comune, come definito dai requisiti del modulo. Un modulo dovrebbe essere autonomo e completo e, sebbene non sia realmente utilizzabile da solo, dovrebbe essere in grado di funzionare in concomitanza con qualsiasi implementazione conforme.
In termini di granularità il componente si trova tra il modulo e l'oggetto. Lo scopo di un componente è mettere insieme una collezione di oggetti di uso generale per formare un'unità specifica allo scopo.
Come suggerisce il nome, a differenza del modulo, il componente non è "autonomo", ma fa parte di un insieme funzionale più ampio.
Gli oggetti sono gli elementi costitutivi più piccoli dei componenti. Gli oggetti sono raccolte di primitivi e li accoppiano per servire un livello più basso, più universale e allo stesso tempo ancora uno scopo specifico.
I primitivi sono il più piccolo, il più semplice e il più basso livello di granularità dello sviluppo del software. In pratica sono solo numeri interi e reali e funzioni / operatori, sebbene la maggior parte delle lingue abbia i propri "cittadini di prima classe" aggiuntivi.
C'è molto poco che puoi fare con i primitivi e, allo stesso tempo, è a un livello così basso che puoi realizzare praticamente tutto con esso. È solo molto, molto prolisso, follemente complicato e impossibilmente noioso da realizzare mentre si lavora direttamente con i primitivi.
Come già accennato in precedenza, lavorare direttamente con i primitivi è una pessima idea. Non solo perché è incredibilmente complesso, lento e noioso da fare per lo sviluppo del software moderno, ma è anche estremamente invadente e ostruttivo ai test e alla manutenzione.
Avere tutte queste parti concettuali incorporate nello sviluppo del software rende tutto più facile, più veloce, più semplice e più sicuro.
Gli umani non inventano davvero nulla, noi scopriamo solo cose già là fuori nell'universo, e poi li copiamo e li applichiamo alle nostre vite. La stessa gerarchia di granularità è intrinseca all'universo stesso, dagli atomi e anche al di sotto, alle molecole organiche, alle proteine, ai tessuti, agli organi, e soprattutto, la realtà stessa obbedisce allo stesso principio - combinando piccole, semplici, funzioni limitate e scopi astratti in più grandi, più complesse, cose più funzionali e cose più specifiche.
Tecnicamente sono tutti "oggetti", sono tutti "componenti" dello sviluppo del software, sono tutti "modulari" abbastanza per essere in grado di stare insieme, sono tutti "prodotti" nel senso che sono stati prodotti e così via ...
Non si tratta di terminologia o nomenclatura, ma di come la scalabilità delle cose influisce su vari aspetti della creatività e della produttività. E sull'importanza di non solo utilizzare tutti quei diversi livelli, ma anche l'importanza di non cercare di raggiungere un obiettivo al livello sbagliato, che può essere solo controproducente.
Dipende dal tuo contesto. Il modulo è già utilizzato per fare riferimento a gruppi di livelli DLL in alcune lingue, come "pacchetto" o "assemblaggio" in altri. Il componente viene utilizzato per le cose COM così come per le componenti basate su entità comuni nello sviluppo del gioco.
In termini generali di architettura, modulo e componente tendono entrambi a riferirsi ad un fascio di codice dietro un'interfaccia ben definita. In generale, il modulo tende a riferirsi a gruppi più grandi. C'è spesso un insieme di interfacce e il modulo tende ad essere in grado di stare da solo.
I componenti d'altra parte tendono ad essere pacchetti di codice più piccoli, spesso più piccoli di una classe completa. Con il loro nome, tendono ad essere un componente di qualcosa di più grande. A volte questa è l'applicazione stessa, ma con l'uso crescente della composizione nel design della classe significa più spesso un componente di un oggetto più grande. Anche le interfacce ben definite per i componenti tendono a consentire all'app di scambiare componenti l'una con l'altra. I moduli tendono a non avere tale possibilità.
Leggi altre domande sui tag design architecture