it-swarm.com.de

Gibt es einen Unterschied zwischen einer Komponente und einem Modul?

Ich habe ein kleines Problem mit den Begriffen Modul und Komponente. In meinen Augen handelt es sich bei einem Modul um gebündelte Klassen, auf die nur über eine genau definierte Schnittstelle zugegriffen werden kann. Sie verbergen alle Implementierungsdetails und sind wiederverwendbar. Module definieren Module, von denen sie abhängen.

Was ist der Unterschied zu Komponenten? Ich habe es in einigen Büchern nachgeschlagen, aber die Beschreibung der Komponenten ist sehr ähnlich.

32
Mirco

Die Begriffe sind ähnlich. Ich stelle mir ein "Modul" im Allgemeinen als größer als eine "Komponente" vor. Eine Komponente ist ein einzelnes Teil, normalerweise von relativ geringem Umfang, möglicherweise für allgemeine Zwecke. Beispiele hierfür sind UI-Steuerelemente und "Hintergrundkomponenten" wie Timer, Threading-Assistenten usw. Ein "Modul" ist ein größeres Teil des Ganzen, das normalerweise eine komplexe Primärfunktion ohne äußere Einflüsse ausführt. Dies kann die Klassenbibliothek einer Anwendung sein, die die Integration mit E-Mail oder der Datenbank ermöglicht. Es kann so groß sein wie eine einzelne Anwendung einer Suite, z. B. das "Debitorenmodul" einer ERP-/Buchhaltungsplattform.

Ich denke auch, dass "Module" austauschbarer sind. Komponenten können repliziert werden, wobei neue wie alte aussehen, aber in gewisser Weise "besser" sind. In der Regel hängt das Design des Systems jedoch strenger von einer Komponente ab (oder von einem Ersatz, der dem spezifischen Verhalten dieser Komponente entspricht). In Nicht-Computer-Begriffen kann eine "Komponente" der Motorblock eines Autos sein; Sie können im Motor basteln, ihn sogar komplett austauschen, aber das Auto muss einen Motor haben und sehr strengen Spezifikationen wie Abmessungen, Gewicht, Montagepunkten usw. entsprechen, um den "Serien" -Motor des Autos zu ersetzen wurde ursprünglich entworfen, um zu haben. Ein "Modul" impliziert andererseits Funktionen vom Typ "Plug-In"; Was auch immer dieses Modul ist, es kann so leicht kommuniziert werden, dass das Modul entfernt und/oder ersetzt werden kann, ohne dass dies Auswirkungen auf andere Teile des Systems hat. Das elektrische System eines Hauses ist sehr modular aufgebaut; Sie können alles mit einem 120V15A-Stecker an jede 120V15A-Steckdose anschließen und erwarten, dass das, was Sie anschließen, funktioniert. Die Hausverkabelung ist es egal, was wo angeschlossen ist, vorausgesetzt, der Strombedarf in einem einzelnen Zweig des Systems überschreitet nicht die Sicherheitsgrenzen.

13
KeithS

Die generische Bedeutung von Modul ist eine Gruppe von wiederverwendbarem Code, der nicht an ein bestimmtes Programm gebunden ist. Dies kann alles sein, von einer ganzen Reihe von GUI-Bibliotheken bis hin zu einer einzelnen Klasse.

Die generische Bedeutung von Komponente ist ein Modul mit der zusätzlichen Einschränkung der Substituierbarkeit unter Verwendung einer bestimmten Schnittstelle. Wenn Sie eine GUI-Widget-Komponente erstellen, kann diese überall dort verwendet werden, wo ein Widget erwartet wird, ohne dass im aufrufenden Code etwas Besonderes erforderlich ist. Module haben im Allgemeinen keine solche Einschränkung. Qt und GTK + sind Module, aber ich kann sie nicht ohne erhebliche Arbeit im aufrufenden Code gegeneinander austauschen, daher sind sie keine Komponenten.

Viele Frameworks oder Programmiersprachen verwenden die Begriffe, um etwas viel Spezifischeres zu bedeuten, weshalb die Leute nach dem Kontext fragen. Etwas kann eine Komponente im allgemeinen Sinne sein, aber wenn es keine sehr spezifische IComponent -Schnittstelle implementiert, wird es möglicherweise nicht als Komponente im Kontext betrachtet. In Python hat module die sehr spezifische technische Bedeutung von etwas, das Sie mit einem Befehl import erhalten können. Normalerweise beziehen sich Menschen auf diese kontextspezifischen Bedeutungen.

12
Karl Bielefeldt

Wenn wir von bestimmten Sprachen, Frameworks und ihren eigenen Interpretationen abstrahieren möchten, lautet die Hierarchie der abstrakten Software-Granularität wie folgt:

Product - application, library, service
  Module - GUI, core logic, data, etc...
    Component - purpose specific collection of objects
      Object - collection of primitives
        Primitive - numbers, functions, etc...
  • Produkt

Das Produkt ist schlicht und einfach eine funktionierende Sammlung verbundener Funktionsmodule.

  • Modul

Wie der Name schon sagt, ist die Motivation eines Moduls die Modularität. Entgegen der Behauptung vieler bedeutet dies nicht wirklich die Wiederverwendung von Code. Es gibt viele Module, die nicht wirklich wiederverwendbar sind und zu nichts passen, für das sie nicht entwickelt wurden.

Es ist wichtig, verschiedene Softwareschichten zu trennen, was die Implementierung und Wartung von Software erheblich vereinfacht. Sollte eine Neuimplementierung in ein anderes GUI-Framework erforderlich sein, ermöglicht die Modularität dies auf einfache und sichere Weise, ohne zu brechen Code überall.

Ein Modul kapselt eine Sammlung von Komponenten, die alle einem gemeinsamen Zweck dienen, wie in den Modulanforderungen definiert. Ein Modul sollte in sich geschlossen und vollständig sein, und obwohl es für sich genommen nicht wirklich verwendbar ist, sollte es in der Lage sein, in Verbindung mit einer konformen Implementierung zu arbeiten.

  • Komponente

In Bezug auf die Granularität befindet sich die Komponente zwischen dem Modul und dem Objekt. Der Zweck einer Komponente besteht darin, eine Sammlung von Allzweckobjekten zu einer zweckspezifischen Einheit zusammenzustellen.

Wie der Name schon sagt, ist die Komponente im Gegensatz zum Modul nicht "in sich geschlossen", sondern Teil eines größeren funktionalen Ganzen.

  • Objekt

Objekte sind die kleineren Bausteine ​​von Komponenten. Objekte sind Sammlungen von Primitiven und koppeln sie zusammen, um einer niedrigeren Ebene zu dienen, die universeller ist und dennoch einen bestimmten Zweck erfüllt.

  • Primitive

Grundelemente sind die kleinste, einfachste und niedrigste Granularität der Softwareentwicklung. Es sind im Grunde nur ganzzahlige und reelle Zahlen und Funktionen/Operatoren, obwohl die meisten Sprachen ihre eigenen zusätzlichen "Bürger erster Klasse" haben.

Mit Primitiven kann man sehr wenig anfangen, und gleichzeitig ist es auf einem so niedrigen Niveau, dass man praktisch alles damit erreichen kann. Es ist einfach sehr, sehr ausführlich, wahnsinnig kompliziert und unglaublich mühsam, wenn man direkt mit Primitiven arbeitet.

  • Was ist der Sinn von all dem?

Wie bereits oben erwähnt, ist die direkte Arbeit mit Grundelementen eine äußerst schlechte Idee. Nicht nur, weil es für die moderne Softwareentwicklung unglaublich komplex, langsam und langwierig ist, sondern auch äußerst aufdringlich und hinderlich für Tests und Wartung.

Wenn all diese konzeptionellen Teile in die Softwareentwicklung integriert werden, wird dies einfacher, schneller, einfacher und sicherer. Sie machen kein Haus aus Atomen, egal wie vielseitig und universell Atome sind. Das wäre eine Übung der Sinnlosigkeit. Ihre Atome sind Ihre Grundelemente, Ton ist Ihr Objekt, Ziegel sind Ihre Komponenten, Wände, Boden und Dach sind Ihre Module, zusammengesetzt manifestieren sie das Endprodukt.

Menschen erfinden eigentlich nichts, wir entdecken nur Dinge, die es bereits im Universum gibt, und kopieren sie dann und wenden sie auf unser Leben an. Dieselbe Granularitätshierarchie ist dem Universum selbst eigen, von Atomen und sogar darunter bis hin zu organischen Molekülen, Proteinen, Geweben, Organen, Organismen und darüber. Die Realität selbst folgt demselben Prinzip - sie kombiniert kleine, einfache, funktionsbeschränkte und zweckmäßige abstrakte Dinge größere, komplexere, funktionalere Dinge und zweckspezifischere Dinge.

  • Terminologische Einschränkungen

Technisch gesehen sind sie alle "Objekte", sie sind alle "Komponenten" der Softwareentwicklung, sie sind alle "modular" genug, um zusammenpassen zu können, sie sind alle "Produkte" in dem Sinne, dass sie hergestellt wurden und so weiter. ..

Hier geht es nicht um Terminologie oder Nomenklatur, sondern darum, wie sich das Vergrößern und Verkleinern verschiedener Aspekte der Kreativität und Produktivität auswirkt. Und darüber, wie wichtig es ist, nicht nur all diese verschiedenen Ebenen zu verwenden, sondern auch, nicht zu versuchen, ein Ziel auf der falschen Ebene zu erreichen, was nur kontraproduktiv sein kann.

9
dtech

Das hängt von Ihrem Kontext ab. Das Modul wird bereits verwendet, um auf DLL Level-Gruppen in einigen Sprachen zu verweisen, ähnlich wie 'package' oder 'Assembly' in anderen Sprachen. Component wird sowohl für COM-Dinge als auch für Entity Based Component-Dinge verwendet, die in häufig vorkommen Spieleentwicklung.

Im Allgemeinen beziehen sich sowohl das Modul als auch die Komponente auf ein Codebündel hinter einer genau definierten Schnittstelle. Im Allgemeinen bezieht sich das Modul eher auf größere Bündel. Es gibt oft eine Reihe von Schnittstellen und das Modul kann in der Regel eigenständig stehen.

Komponenten hingegen sind in der Regel kleinere Codebündel, die häufig kleiner als eine vollständige Klasse sind. Mit ihrem Namen neigen sie dazu, Bestandteil von etwas Größerem zu sein. Manchmal ist das die Anwendung selbst, aber mit der zunehmenden Verwendung von Komposition im Klassendesign bedeutet dies häufiger eine Komponente eines größeren Objekts. Die gut definierten Schnittstellen für Komponenten ermöglichen es der App auch, Komponenten gegeneinander auszutauschen. Module neigen dazu, diese Austauschbarkeit nicht zu haben.

3
Telastyn