C'è una differenza tra un componente e un modulo

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? L'ho cercato in alcuni libri, ma la descrizione dei componenti è molto simile.

I termini sono simili In genere penso a un "modulo" come più grande di un "componente". Un componente è una singola parte, generalmente di portata relativamente piccola, possibilmente per scopi generici. Gli esempi includono controlli dell'interfaccia utente e "componenti di sfondo" come timer, threading assistants ecc. Un "modulo" è un pezzo più grande del tutto, di solito qualcosa che svolge una funzione primaria complessa senza interferenze esterne. Potrebbe essere la libreria di classi di un'applicazione che fornisce l'integrazione con la posta elettronica o il database. Può essere grande come una singola applicazione di una suite, ad esempio il "Modulo contabilità clienti" di una piattaforma ERP / contabile.

Penso anche ai "moduli" come più intercambiabili. I componenti possono essere replicati, con quelli nuovi che sembrano vecchi ma in qualche modo "migliori", ma in genere la progettazione del sistema dipende più strettamente da un componente (o 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'auto; puoi armeggiare all'interno del motore, anche sostituirlo interamente, ma l'auto deve avere un motore e deve essere conforme a specifiche molto rigide come dimensioni, peso, punti di montaggio, ecc. per sostituire il motore "di serie" che l'auto è stato originariamente progettato per avere. Un "modulo", d'altra parte, implica la funzionalità di tipo "plug-in"; qualunque sia quel modulo, può essere comunicato in modo così leggero che il modulo può essere rimosso e / o sostituito con un effetto minimo su altre parti del sistema. Il sistema elettrico di una casa è altamente modulare; puoi collegare qualsiasi cosa con una presa da 120 V 15 A in qualsiasi presa da 120 V 15 A e aspettarti che funzioni ciò che stai collegando. Il cablaggio della casa non potrebbe importare di meno di ciò che è collegato, a condizione che le richieste di alimentazione in ogni singolo ramo del sistema non superino i limiti di sicurezza.

Il significato generico di module è un gruppo di codice riutilizzabile, non legato a un programma specifico. Potrebbe trattarsi di tutto, da un intero set di librerie GUI fino a una singola classe.

Il significato generico di componente è un modulo con l'ulteriore limitazione della sostituibilità mediante un'interfaccia specifica. Se si crea un componente Widget GUI, può essere utilizzato ovunque sia previsto un Widget, senza dover fare nulla di speciale nel codice chiamante. I moduli in generale non hanno questa limitazione. Qt e GTK + sono moduli, ma non posso scambiarne uno senza l'altro senza un considerevole 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 del contesto. Qualcosa può essere un componente in senso generico, ma se non implementa un'interfaccia molto specifica IComponent, potrebbe non essere considerato un componente nel contesto. In Python, moduleha il significato tecnico molto specifico di qualcosa che puoi ottenere usando un importcomando. Di solito le persone si riferiscono a questi significati specifici del contesto.

Se vogliamo astrarre da particolari linguaggi, quadri e loro interpretazioni, la gerarchia di 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...

• Prodotto

Chiaro e semplice, il Prodotto è una raccolta funzionante di moduli funzionali collegati.

• Modulo

Come suggerisce il nome stesso, la motivazione di un modulo è la modularità. Contrariamente a quanto sostengono molti, non implica davvero il riutilizzo del codice. Esistono molti moduli che non sono realmente riutilizzabili e non si adattano a nulla per cui non sono stati progettati.

È importante separare diversi livelli software, il che rende il software molto più facile da implementare e mantenere e, se fosse necessario reimplementare qualcosa come un front-end in un diverso framework GUI, la modularità consente che ciò avvenga in modo facile e sicuro, senza rompere 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 insieme a qualsiasi implementazione conforme.

• Componente

In termini di granularità, il componente si trova tra il modulo e l'oggetto. Lo scopo di un componente è quello di mettere insieme una raccolta di oggetti di uso generale per formare un'unità specifica di scopo.

Come suggerisce il nome, a differenza del Modulo, il Componente non è "autonomo", fa parte di un insieme funzionale più ampio.

• Oggetto

Gli oggetti sono i mattoni più piccoli dei componenti. Gli oggetti sono raccolte di primitivi e li accoppiano per servire a un livello più basso, più universale pur mantenendo uno scopo in qualche modo specifico.

• Primitivo

I primitivi rappresentano il livello più piccolo, più semplice e più basso di granularità nello sviluppo del software. Fondamentalmente è 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 praticamente realizzare tutto con esso. È solo molto, molto dettagliato, follemente complicato e incredibilmente noioso da realizzare mentre si lavora direttamente con i primitivi.

• Qual è il punto di tutto questo?

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 di software moderno, ma è anche estremamente invadente e ostruttivo per i test e la manutenzione.

Avere tutte quelle parti concettuali incorporate nello sviluppo del software rende tutto più semplice, veloce, semplice e sicuro. Non costruisci una casa con gli atomi, indipendentemente da quanto siano versatili e universali gli atomi. Sarebbe un esercizio di futilità. I tuoi atomi sono i tuoi primitivi, l'argilla è il tuo oggetto, i mattoni sono i tuoi componenti, le pareti, il pavimento e il tetto sono i tuoi moduli, assemblati insieme manifestano il prodotto finale.

Gli umani non inventano davvero nulla, scopriamo solo cose già là fuori nell'universo, quindi le copiamo e le 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, agli organismi e al di sopra, la realtà stessa obbedisce allo stesso principio - combinando piccole, semplici funzioni limitate e scopo cose astratte in cose più grandi, più complesse, più funzionali e cose più specifiche per scopi.

• Avvertenze terminologiche

Tecnicamente sono tutti "oggetti", sono tutti "componenti" dello sviluppo del software, sono tutti "modulari" abbastanza da poter stare insieme, sono tutti "prodotti" nel senso che sono stati prodotti e così via. ..

Non si tratta di terminologia o nomenclatura, ma di come il ridimensionamento delle cose influenzi vari aspetti della creatività e della produttività. E sull'importanza di non solo usare 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 livello DLL in alcune lingue, simile a "pacchetto" o "assembly" in altri. Componente è usato per le cose COM così come per le componenti basate su entità comuni nello sviluppo del gioco.

In termini architettonici generali, modulo e componente tendono entrambi a fare riferimento a un fascio di codice dietro un'interfaccia ben definita. In generale, il modulo tende a fare riferimento a fasci più grandi. C'è spesso una serie di interfacce e il modulo tende a stare in piedi da solo.

I componenti invece tendono ad essere fasci di codice più piccoli, spesso più piccoli di una classe completa. Con il loro nome, tendono ad essere una componente di qualcosa di più grande. A volte questa è l'applicazione stessa, ma con il crescente utilizzo della composizione nel design di classe significa più spesso un componente di un oggetto più grande. Le interfacce ben definite per i componenti tendono anche a consentire all'app di scambiarsi i componenti l'uno con l'altro. I moduli tendono a non avere quella scambiabilità.