Ich habe einige Java-Programme, jetzt möchte ich herausfinden, ob es modular ist oder nicht, wenn es modular ist, bis zu welchem Ausmaß, denn Modularität kann nie binärer Begriff sein, dh 0 oder 1. Wie entscheide ich das speziell Der Code ist bis zu diesem Grad modular. Ich möchte wissen, wie man Code viel modularer macht?Wie man Code modular macht?
Angenommen, ich verstehe Ihre Frage, dass Sie wissen wollen, was Code modular macht, da Code-Module offensichtlich eine Abhängigkeit brauchen, um überhaupt funktionieren zu können. Dies ist meine Antwort:
Wenn Sie Ihr System in Module zerlegen können, und Sie können diese Module isoliert testen, ist dies ein guter Hinweis darauf, dass ein System modular ist.
Wie Sie sagen, Modularität ist keine binäre Sache, so hängt es von Ihrer relativen Definition.
Ich würde sagen: Können Sie eine bestimmte Methode in jedem Programm verwenden, in dem Sie diese Funktion ausführen müssen? Ist es die "Black Box", in der man nicht wissen müsste, was es unter der Motorhaube macht? Wenn die Antwort nein ist, d. H. Die Methode würde nur in diesem Programm funktionieren, dann ist sie nicht wirklich modular.
Modularität ist relativ zu dem, der jemals den Code entwickelt. Aber ich denke, der allgemeine Konsens besteht darin, dass modularer Code Code ist, der Teile hat, die leicht ausgetauscht werden können, ohne den ursprünglichen Code weitgehend zu verändern.
IMHO, Wenn Sie 3 Module A B und C haben und Sie Modul C vollständig ändern oder ersetzen möchten, wenn es eine einfache Aufgabe ist, dann haben Sie modularen Code.
Sie können ein Codeanalyse-Tool wie CAP verwenden, um die Abhängigkeiten zwischen Typen und Paketen zu analysieren. Sie helfen Ihnen dabei, zyklische Abhängigkeiten zu finden und zu entfernen, die bei der Entwicklung von modularem Code oft ein Problem darstellen. Wenn keine zyklischen Abhängigkeiten vorhanden sind, können Sie beginnen, Ihren Code in einzelne Gläser zu trennen.
Im Allgemeinen ist es eine gute Übung, an Schnittstellen zu codieren, wenn Sie können, dies bedeutet im Allgemeinen, dass Ihr Code leichter refaktoriert und/oder in verschiedenen Kontexten verwendet werden kann.
Abhängigkeits-Injection-Frameworks wie Spring können auch bei der Modularität Ihres Designs helfen. Wenn Typen durch einen externen Konfigurationsprozess mit ihren Abhängigkeiten verknüpft werden, benötigen sie keine direkte Abhängigkeit von einer Implementierung.
einige Benchmarks für Modularität:
Für weitere Ideen check this out und dieses auf software quality
Wie für Ihr Interesse auf machen Ihren Code modular zuerst sollten Sie sich die oben genannten Fragen stellen, erhalten konkrete Antworten für sie und dann einen Blick bei this
Die Grundphilosophie ist Ihre Anwendung in so kleine Codefragmente wie möglich ordentlich über eine Vielzahl von leicht verständlicher und zugänglichen Verzeichnisstruktur angeordnet zu brechen.
Jede Methode in Ihrer Anwendung muss nicht mehr als die Mindestquanten der Verarbeitung benötigt. diese Methoden in immer mehr Makroebene Methoden Kombinieren sollten Sie zurück zu Ihrer Anwendung
Ein anderer Benchmark könnte das "Löschkriterium" sein: Wenn Sie X (Paket, Klasse, Methode, Feld) aus Ihrem Programm löschen, was passiert dann? Wenn es Pausen gibt, wie "weit entfernt" sind sie vom gelöschten Gegenstand? Wenn die zerbrochenen Gegenstände entfernt sind, bedeutet das, dass X weniger modular war. –
(Zum vorherigen Kommentar hinzufügen) - Wenn Sie etwas löschen, stellen Sie sofort seine Verbindungen mit dem Rest des Programms - alle Orte, wo es mit dem Anrufcode verdrahtet ist. Mehr Modularität * normalerweise * bedeutet weniger Verbindungspunkte und bedeutet normalerweise, dass die Verbindungspunkte im Bereich "lokaler" sind (z. B. innerhalb eines einzelnen Pakets). –
+1! absolut korrekt! – OrangeRind
Kernpunkte führen, sind
Ein gutes Beispiel für ein solches Modulsystem sind Standard-Autoteile wie Scheibenbremsen und Autoradio. Sie möchten nicht Auto-Stereo von Grund auf neu bauen, wenn Sie Autos bauen. Sie würden es lieber kaufen und einstecken. Sie wollen auch nicht, dass das Bremssystem das Autoradio beeinflusst - oder ein schlechteres Autoradio das Bremssystem beeinträchtigt.
Um Ihre Frage zu beantworten, "Wie entscheide ich, dass bestimmter Code in diesem Ausmaß modular ist", können wir Fragen stellen, um die Modularität zu testen. Können Sie Ihre Module einfach durch etwas anderes ersetzen, ohne andere Teile Ihrer Anwendung zu beeinflussen?
XML-Parser könnten ein weiteres Beispiel sein. Sobald Sie die DOM-Schnittstelle erhalten, ist es Ihnen egal, welche Implementierung des XML-Parsers darunter verwendet wird (z. B. Apache Xerces oder JAXP).
In Java kann eine andere Frage sein: Sind alle Funktionen über interface s zugänglich? Interface sorgt ziemlich gut für die niedrige Kopplung.
Auch können Sie jedes Modul in Ihrem System mit einem Satz beschreiben? Zum Beispiel spielt ein Autoradio Musik und Radio. Scheibenbremsen verzögern das Fahrzeug sicher.
(Hier ist, was ich zu What is component driven development? schrieb)
Laut Wikipedia, komponentenbasierte Entwicklung ist ein Alias für Component-based software engineering (CBSE).
[Es] ist ein Zweig der Software Engineering, deren Priorität ist die Trennung von Bedenken in Bezug der weitreichenden Funktionalität verfügbar über einen Software System gegeben.
Dies ist etwas vage, also schauen wir uns weitere Details an.
Einzelkomponente ist ein Software-Paket , oder ein Modul, das einen Satz verwandter Funktionen kapselt (oder Daten).
alle Systemprozesse platziert sind in separate Komponenten so, dass alle der Daten und Funktionen innerhalb jeder Komponente semantisch verwandte (ebenso wie mit dem Inhalt der Klassen). Aufgrund dieses Prinzips wird oft gesagt, dass die Komponenten modular und kohäsiv sind.
Also, nach dieser Definition kann eine Komponente alles sein, solange es eine Sache wirklich gut und nur eine Sache tut.
Im Hinblick auf die systemweite Koordination, Komponenten kommunizieren miteinander über Schnittstellen . [...] Dieses Prinzip führt zu Komponenten, die als gekapselt bezeichnet werden.
Das klingt mehr und mehr nach dem, was wir von einer guten API oder SOA halten.
Die vorgesehen Schnittstellen durch einen Lutscher vertreten sind und erforderlich Schnittstellen durch ein offenes Buchse Symbol an den äußeren Rand des Bauteils in UML angebracht dargestellt sind.
Ein weiteres wichtiges Merkmal von Komponenten ist, dass sie sind substituierbar, so dass eine Komponente durch eine andere ersetzt werden kann (bei Entwurfszeit oder Laufzeit), wenn die Anforderungen der initialen Komponente (ausgedrückt über die Schnittstellen) werden von der Nachfolgekomponente erfüllt.
Wiederverwendbarkeit ist eine wichtige Eigenschaft einer hochwertigen Softwarekomponente. Eine Software Komponente sollte entworfen und implementiert werden, so dass es in vielen verschiedenen Programmen wiederverwendet werden kann.
Substituierbarkeit und Wiederverwendbarkeit macht eine Komponente zu einer Komponente. Was ist der Unterschied zwischen dieser und der objektorientierten Programmierung?
Die Idee in der objektorientierten Programmierung (OOP) ist, dass Software sollte Objekte der tatsächlichen oder vermeintlichen gemäß einem gedankliches Modell geschrieben werden sie darstellt. [...]
Komponentenbasierte Software-Engineering, dagegen macht keine solchen Annahmen und stattdessen erklärt, dass Software sollte durch Kleben vorgefertigten Komponenten zusammen viel wie auf dem Gebiet der Elektronik oder entwickelt werden Mechanik.
Um Ihre spezifischen Frage der zu beantworten, wie den Code modular, ein paar Ansätze zu machen sind:
Eines der besten Werkzeug für Modularisierung ist Spek Code Wiederverwendung. Wenn Sie feststellen, dass Ihr Code die gleiche (oder sehr ähnliche) Sache mehr als einmal vornimmt, ist dies ein guter Kandidat für die Modularisierung.
Bestimmen Sie, welche Teile der Logik können unabhängig gemacht werden, in einem Sinne, dass andere Logik würde sie verwenden, ohne zu wissen, wie sie gebaut sind. Dies ist etwas ähnlich zu dem, was Sie in OO Design, obwohl Modul/Komponente muss nicht unbedingt zu einem modellierten Objekt wie in OO entsprechen.
Die Idee package-by-feature hilft, Code modularer zu machen.
Viele Beispiele auf der Web-divide Anwendungen in Schichten zuerst gesehen, gehört nicht
Es scheint jedoch besser, zu teilen Anwendungen Verwendung von Top-Level-Paketen, die mit Features ausgerichtet sind, nicht Ebenen.
Hier ist eine example einer Webanwendung, die Paket-für-Funktion verwendet. Notieren Sie sich die Namen der Top-Level-Pakete, die als Liste der tatsächlichen Features in der Anwendung gelesen werden. Beachten Sie auch, wie jedes Paket alle Elemente enthält, die sich auf ein Feature beziehen - die Elemente sind nicht überall verteilt; die meiste Zeit sind sie alle in einem einzigen Paket/Verzeichnis.
Normalerweise kann das Löschen eines Features in einer solchen App in einem einzigen Vorgang implementiert werden - Löschen eines einzelnen Verzeichnisses.
Da dies mit 'osgi' getaggt wurde, kann ich eine OSGi-bezogene Perspektive einwerfen.
Die kurze Antwort ist, dass es möglich ist, in kleinen Schritten von völlig Spaghetti-Code zu modularem zu gehen; es muss kein großer Knall sein. Zum Beispiel, sogar Spaghetti-Code hängt von einer Art von Bolognese Logging-Bibliothek ab, in gewisser Weise ist es bereits modular, nur mit einem sehr großen Metball (Entschuldigung, Modul) darin.
Der Trick ist, den großen Fleischbällchen in einen kleineren Brocken und dann einen etwas weniger großen Fleischbällchen zu brechen und dann zu rekrutieren. Es muss auch nicht alles auf einmal getan werden; Einfach jedes Mal etwas mehr abschneiden, bis nichts mehr übrig ist.
Wie für OSGi ist es immer noch möglich, ein Uber-Glas in ein Bündel zu legen. In der Tat können Sie dies tun, ohne die Bits zu ändern; Entweder indem Sie die Manifest.MF-Datei an Ort und Stelle ändern oder diese in eine andere JAR-Datei einfügen und Bundle-ClassPath: metaball.jar im Manifest angeben.
Andernfalls können Tools wie BND helfen, die richtigen Daten zu generieren, die Sie benötigen, und dann kann es in einer OSGi-Laufzeit problemlos gelöscht werden. Aber hüte dich vor übermäßigem Code und Dingen, die sich mit Klassenlehrern herumschlagen - diese werden dich stolpern.
Hej,
Siehe "Wie Software (Teil 1) kapseln," hier:
http://www.edmundkirwan.com/encap/overview/paper7.html
Grüße,
Ed.
Wenn Code wirklich modular ist, sollte jede Komponente eine Blackbox sein. Je weniger Wissenskomponenten über einander wissen, desto modularer ist das System. – Kevin