Ich möchte meine Idee zu diesem Unterschied teilen.
Sowohl Komponente als auch Modul werden verwendet, um auf eine Gruppe von Funktionen oder einen Teil einer Funktion zu verweisen. Das Modul ist logischer, zum Beispiel: Modul Finanzen, Modul HR, Modul Fertigung ... im ERP System. Andererseits ist die Komponente physischer. In der Software kann es sich um eine DLL, OCX, EXE, ... handeln.
Es gibt keine Kriterien zu messen, welches größer als das andere ist. Eine Komponente kann eine Liste von Modulen enthalten, und ein Modul kann auch viele Komponenten enthalten. Komponenten dienen zur Modellierung eines Systems in der technischen Sicht und Module zur Modellierung des Systems in der Funktionssicht (Funktionalitäten des Systems).
Es gibt eine Referenz in OSGi in Aktion, die meiner Meinung nach erklärt, dass die Unterschiede sehr gut sind.
Module vs. Komponenten Klingt es nicht so, als hätten Module und Komponenten viel gemeinsam? Beide versorgen sich gegenseitig und konsumieren sich gegenseitig. Sie sind auch als unabhängige Bereitstellungseinheiten verpackt. Könnten diese beiden nicht als ein und dasselbe angesehen oder zumindest kombiniert werden? Ja, das könnte sein, aber Komponenten und Module dienen unterschiedlichen Zwecken und sind rechtwinklig (sie sind nicht vollständig rechtwinklig, da Komponenten aus Code bestehen, der letztendlich in Module verpackt werden kann). Module beschäftigen sich mit Code-Paketierung und den Abhängigkeiten zwischen Code. Komponenten befassen sich mit der Implementierung übergeordneter Funktionen und den Abhängigkeiten zwischen Komponenten. Komponenten müssen ihre Code-Abhängigkeiten verwalten, aber technisch benötigen sie kein Modul-System, um dies zu tun (oft sind es wir Programmierer, die dies über den Klassenpfad tun). Eine gute Zusammenfassung ist, dass Sie sich Module so vorstellen können, dass sie sich mit statischem Code und Abhängigkeiten zur Kompilierungszeit befassen, während sich Komponenten mit Instanzen und Abhängigkeiten zur Ausführungszeit befassen.
Komponenten und Module werden zu oft miteinander verwechselt. Sie sind jedoch nicht gleich, und die Implikationen des einen gelten nicht unbedingt für das andere.
Modularität ist die Aufteilung von Code in Module mit verwandter Funktionalität. In vielen Programmiersprachen ist ein Modul einfach eine Quelldatei. Wenn die Quelldatei zu groß wird, können Sie sie in zwei oder mehr Quelldateien aufteilen und diese in ein neues Verzeichnis verschieben. Während ein Verzeichnis oft nicht als Modul bezeichnet wird, ist diese Art der Zerlegung immer noch modular.
Andererseits kann eine Komponente auf unterschiedliche Weise mit anderen Komponenten zusammengesetzt werden, um unterschiedliche Programme zu bilden. Das heißt, es gibt eine separate Kompositionsphase, in der echte Personen entscheiden, welche Komponenten zusammen verwendet werden sollen.
Ich habe gesehen, wie das Komponentendesign verwendet wurde, um eine Vorstellung von harter Modularität durchzusetzen. Dieser Ansatz kann aufgrund des erheblichen Mehraufwands für die Komposition nicht empfohlen werden: Die Komplexität der Komposition wächst polynomiell mit der Anzahl der Komponenten. Und die Anzahl der Komponenten wächst linear mit der Anzahl der Funktionsgruppen. Wenn Sie erst einmal mit der Modularität durch Komponentenzerlegung begonnen haben, müssen Sie immer dann eine neue Komponente erstellen, wenn Sie ansonsten nur ein neues Modul benötigen, da dies ansonsten nicht der Fall wäre wirklich überall hingehören. Bei 100 Komponenten wurde der Kompositionsaufwand zu einem Vollzeitjob, und jede Kompositionsiteration würde trotz zahlreicher Automatisierungsbemühungen einige Wochen in Anspruch nehmen. Dies hat die Entwicklung erheblich behindert.
Am einfachsten empfehle ich, sich von Bauteilen fernzuhalten, wenn dies überhaupt möglich ist. Gut zu wissen, dass Komponenten manchmal eine Notwendigkeit sein können. Wenn beispielsweise mehrere unabhängige Organisationen an einem Projekt beteiligt sind, erscheint eine Komponente für jede Organisation akzeptabel.
Es ist Geschmackssache, wie feinkörnig Ihre Zerlegung in Module sein sollte, obwohl alle der Meinung sind, dass Modularität eine gute Sache ist.
Wenn ich den Namen einer Funktion kenne, wird mein Editor ihn früh genug finden. Wenn ich andererseits aus irgendeinem Grund den Namen einer Funktion (oder einer Klasse) nicht kenne, wird Modularität wichtiger.
Ich würde erwarten, dass der spätere Fall nur ein Problem für die Funktionalität darstellt, die Sie durch die Verwendung des Programms erfahren können. Versuchen Sie daher, die Zerlegung Ihres Programms in Module so zu gestalten, dass sie eine intuitive Zerlegung des Verhaltens Ihres Programms in Funktionsbereiche widerspiegelt.
Wenn Sie Modul im Sinne von Modularität meinen, gibt es eine Definition im IEEE Standard Glossar der Software Engineering Terminologie:
"Modularität ist der Grad, in dem ein System oder Computerprogramm aus diskreten Komponenten besteht, sodass eine Änderung an einer Komponente nur minimale Auswirkungen auf andere Komponenten hat."
Und Dr. Bertrand Meyer nannte fünf Kriterien für die Modularität:
- Zerlegbarkeit des Problems in Teilprobleme
- Zusammensetzbarkeit von Modulen zur Herstellung neuer Systeme
- Verständlichkeit eines Moduls für sich
- Kontinuität - kleine Änderungen haben lokalisierte Auswirkungen
- Schutz - Fehlerisolation
Für die digitale Entwicklung und die Berücksichtigung der Benutzeroberfläche (HTML/CSS/JS) verwende ich diesen Ansatz, um sicherzustellen, dass ich organisiert bin und überlege, bevor ich etwas tue. Es hat sich gezeigt, dass sauberer, besser organisierter Code erstellt wird, der sich gut dazu eignet, mit weniger mehr zu erreichen.
In einem typischen Stylesheet richte ich derzeit Folgendes ein:
/* Style Guide – Mobile First
1. =Setup
2. =Modules as independent units made up of components
3. =Components as group of reusable code containing more than one element
4. =Classes
5. =Responsive as enhancement
*/
- Module als eigenständige Einheiten aus Komponenten: Kopfzeile, Fußzeile, Abschnitte, Artikel, Nebeneinander usw. Ein Haus besteht aus vielen Räumen, die alle besondere Stile und Funktionen haben, um ein eigenständiges Ganzes zu bilden.
- Komponenten als Gruppe von wiederverwendbarem Code mit mehr als einem Element: ungeordnete Listen, Anführungszeichen, Karten, Tabellen usw.
Ich habe eine ausführlichere Erklärung geschrieben, die Sie lesen können hier .
Hoffe das hilft!
Aus meiner Sicht sind Module und Component nur einige Funktionen und Assets.
Und der Unterschied zwischen ihnen ist:
Komponente hat Geschäftslogik und Modul nicht.
Dieser Texteingabebereich ist zum Beispiel nur ein Modul, aber als eine Post-API aufgerufen wurde, wurde sie zu einer Komponente. Sie können ein Modul überall platzieren und es wird gut funktionieren, aber Componet kann nur in einer bestimmten Seite oder Ansicht verwendet werden (weil es einen bestimmten API-Aufruf hat)
Die Komponente ist eine Laufzeitentität (kann aus Modulen bestehen), eine unabhängige ausführbare Einheit
Das Modul ist ein in Implementierungseinheiten unterteiltes System mit unabhängiger Aufgabenzuweisung. Module können eine Komponente sein oder nicht