[JAVA] [Buchbesprechung] Saubere Architektur Struktur und Design der Software von Meistern gelernt

Das Buch, das ich gelesen habe

Struktur und Design der sauberen Architektur-Software von Mastern gelernt Robert C. Martin Autor Ich lese. Es ist eine Buchbesprechung (Leseeindruck).

Design- und Architekturziele

Der Autor argumentiert zunächst für Design und Architektur (der Autor sagt Design = Architektur). Sagt `" Der Zweck der Softwarearchitektur besteht darin, den Personalaufwand für den Aufbau und die Wartung des erforderlichen Systems zu minimieren. " Für einen Moment wurde es "Hmm?" Und ich dachte, es könnte nach einer Weile so sein. Hier geht es nicht um Hobbys, sondern um die Entwicklung von Software als Unternehmen. Es mag Ingenieuren nicht in den Sinn kommen, die denken, dass es ein Job ist, aber Menschen, die es als Hobby machen und keine Wartung kennen, aber es ist aus geschäftlicher Sicht sicherlich richtig. Übrigens bin ich ein Ingenieur, der mit der Entwicklung von Software aufgewachsen ist und dabei die ganze Zeit Spaß hat. Ich denke also nicht, dass es schlecht für einen Ingenieur ist, der gerne frei von Geschäften ist. (Nur einen Untergebenen zu haben, wäre ein Schmerz ...)

Mit anderen Worten ** "Software, die in Entwicklung und Wartung nicht produktiv ist, ist schlecht konzipiert" ** Deshalb ist es ziemlich vernünftig. Es ist ein ** das **, das jedes Mal, wenn etwas geändert wird, einen riesigen Mannmonat erfordert. Außerdem wird es mit den Tagen immer schlimmer.

Wie entwerfe ich? Bis zum zweiten Teil fühlt es sich an, als würde man auf die Geschichte zurückblicken. Überspringen Sie sie daher vorerst. Teil 3 SRP: Prinzip der Einzelverantwortung OCP: Prinzip des offenen / geschlossenen LSP: Prinzip des Austauschs von Liskov ISP: Prinzip der Schnittstellentrennung
DIP: Prinzip der Abhängigkeitsumkehr

Ist es hier? Dies sind Akronyme ** SOLID Principles **. Dies sind gültige Ideen für ** "Detailentwurf" ** und nicht ** "Grundentwurf" ** des Systems. Der Autor sagt auch, dass es "über der Codeebene gilt" und ** Komponentendesign ** weiter wartet. Wenn Sie zu ** Komponentendesign ** gehen, fällt es in die Kategorie ** "Basisdesign" **.

Aber zuerst "SRP: Prinzip der Einzelverantwortung"

SRP: Prinzip der Einzelverantwortung

Dies ist eine ziemlich verwirrende Erklärung in diesem Buch, aber nach meinem eigenen Verständnis ist es so.

** Verantwortung sollte MECE sein **

Was ist MECE? Für diejenigen, die sagen Lernen Sie die Grundlagen von 5 Frameworks, was ist "MECE" Bitte sehen Sie sich um. Einfach ausgedrückt ist MECE eine Abkürzung für "gegenseitig ausschließend und kollektiv erschöpfend", was "ohne Auslassungen und ohne Vervielfältigung" bedeutet. Ursprünglich McKinseys interner Begriff, ich denke, Sie werden ihn heutzutage oft im Thema logisches Denken sehen. Ich denke nicht, dass MECE in Ordnung ist, aber es ist ein sehr gutes Konzept, um das "Prinzip der Einzelverantwortung" zu erklären. Ich denke, dass diese Idee für die Analyse aller Ereignisse effektiv ist und wertvoll ist, wenn sie auf jeder Ebene des grundlegenden Designs und der Anforderungen angewendet wird und nicht auf der Ebene des detaillierten Designs.

OCP: Offenes / Geschlossenes Prinzip

Unter Berücksichtigung der Richtung der Einkapselung und Abhängigkeit sagt er: "Es sollte möglich sein, vorhandene Artefakte ohne Modifikation zu erweitern." Das Problem ist, was die ** vorhandenen Ergebnisse ** sind, aber im Grunde Kernteil wie Geschäftslogik Oder "Die Seite, die sich in der unteren Schicht in der hierarchischen Struktur befindet und von der oberen Schicht aufgerufen wird" (allgemein) Das wäre der Fall. Klassen, Module, Komponenten usw., die als ** vorhandene Artefakte ** bezeichnet werden, müssen natürlich ordnungsgemäß durch das "Prinzip der Einzelverantwortung" berücksichtigt werden. Klassen, Module, Komponenten usw., deren Verantwortlichkeiten richtig aufgeteilt sind und nur von außen aufgerufen werden, sind natürlich von externen Änderungen isoliert, so dass gesagt werden kann, dass sie dem ** offenen / geschlossenen Prinzip ** folgen. ..

LSP: Liskovs Ersatzprinzip

Das Prinzip und das Verständnis von Protokoll in Swift, Schnittstelle in Java und Implementierungsobjekten für abstrakte Klassen in C ++ sollten sich wie in diesen Schnittstellendefinitionen definiert verhalten. Wenn die Schnittstellendefinition korrekt und klar ist, müssen Sie vorsichtig sein, da Sie sie nur genau implementieren, aber sie scheint nicht sehr wichtig zu sein.

ISP: Prinzip der Schnittstellentrennung

Ich denke, das Prinzip lautet "nicht unnötig von anderen abhängig sein" und "nicht unnötig von anderen abhängen". Wenn die Aufteilung der Zuständigkeiten MECE ist und das "offene und geschlossene Prinzip" verwendet wird, um Abhängigkeiten zu minimieren und die richtige Schnittstelle zu entwerfen, werden ** Abhängigkeiten ** natürlich abnehmen.

Es genügt zu sagen, dass in der Abhängigkeit von einer Schnittstelle, wie im "Prinzip der Abhängigkeitsumkehr" unten beschrieben, die Idee, dass eine Klasse mehrere Schnittstellen definiert und die andere Klasse nicht zwingt, unnötige Funktionen zu implementieren. Kann wichtig sein.

DIP: Prinzip der Abhängigkeitsumkehr

Es ist fast kein Leseeindruck mehr, aber ich möchte auch hier meine eigene Meinung schreiben.

Erstens ist die Abhängigkeit die Richtung des Joins. Wie im "Open / Closed-Prinzip" erwähnt, wird A zu B, wenn sich A in der oberen Schicht (im Folgenden als "A-Schicht" bezeichnet) und B in der unteren Schicht (im Folgenden als "B-Schicht" bezeichnet) befindet. Selbst wenn es darauf ankommt, glaubt B, dass es nicht viel Problem verursachen wird, da es überhaupt nur wenige Änderungen gibt.

A in der oberen Schicht ist jedoch ein invariantes Modul und ich möchte nicht von B abhängen. Aber was ist, wenn Sie die B-Funktion aufrufen müssen?

Die Antwort lautet ** "Umkehrung von Abhängigkeiten" **.

Insbesondere hängt es von der Schnittstelle ab (Swift Protocol, Java Interface) und nicht von der Implementierung (Objektinstanz), oder? Das ist das "Prinzip der Abhängigkeitsumkehr".

In der oben gezeigten Situation hängen sowohl A als auch B von der Schnittstelle ab. A ruft nur die in der Schnittstelle definierte Funktion von B auf, egal wer B ist. B ist nicht von A abhängig, indem es so implementiert wird, dass es nicht gegen die Definition der Schnittstelle verstößt („Riskovs Substitutionsprinzip“). Ich denke, dass der Ausdruck ** Umkehrung ** wegen der Abhängigkeit dieser Schicht-A-Schnittstelle verwendet wird.

Aber ich bin ein wenig skeptisch, dass es an dem Besitzer der ** Schnittstelle ** liegt, zu sehen, ob es umgekehrt ist. Mit anderen Worten, ist der Eigentümer der Definition der Schnittstelle A oder B?

In Anbetracht der oben gezeigten Konfiguration kann nicht gesagt werden, dass es sich um eine Umkehrung handelt. Es scheint, dass Schicht B eine Schnittstelle mit einem bestimmten Ziel definiert, eine Instanz von B zu verbergen.

Auf diese Weise hat die Tatsache, dass es von der Benutzeroberfläche selbst abhängt, eine Bedeutung im Entwurfsmuster, und es ist ehrlich, dass Sie sich keine Gedanken über die Umkehrung machen müssen.

Zusammenfassung

** Saubere Architektur Ich habe gerade meine Gedanken geschrieben und nicht den Inhalt der Softwarestruktur und des Softwaredesigns, die ich von den Meistern gelernt habe **, aber ich werde es einmal zusammenfassen.

Wichtig bei der detaillierten Gestaltung von Klassenmodulkomponenten ist

Stellen Sie sich Ihre Verantwortung als MECE vor
Über die Richtung der Abhängigkeit nachdenken
Verlassen Sie sich nicht unnötig darauf, hängen Sie nicht davon ab
Verlassen Sie sich bei Bedarf auf die Schnittstelle

Ich denke. Fast ** Splits und Abhängigkeiten ** werden erwähnt.

Schließlich ist die folgende Tabelle angegeben. Kann ich eines Tages über Teil 4 und Teil 5 schreiben ...

Inhaltsverzeichnis

Teil 1 Einleitung
Design und Architektur
Zwei-Werte-Geschichte
Teil 2 Beginnen Sie mit den Komponenten:Programmierparadigma
Überblick über das Paradigma
Strukturierte Programmierung
Objekt orientierte Programmierung
Funktionsprogrammierung
Teil 3 Gestaltungsprinzipien
SRP: Prinzip der Einzelverantwortung
OCP: Offenes / Geschlossenes Prinzip
LSP: Liskovs Ersatzprinzip
ISP: Prinzip der Schnittstellentrennung
DIP: Prinzip der Abhängigkeitsumkehr
Teil 4 Komponentenprinzipien
Komponente
Komponentenkondensation
Komponenten kombinieren
Teil 5 Architektur
Was ist Architektur?
Unabhängigkeit
Grenze: Zeichnen Sie eine Grenze
Grenzanatomie
Politik und Ebene
Geschäftsregeln
Schreiende Architektur
Saubere Architektur
Moderator und bescheidenes Objekt
Teilgrenze
Ebenen und Grenzen
Hauptbestandteil
Service: Alles
Testgrenze
Saubere eingebaute Architektur
Teil 6 Details
Kürzung
Teil 7 Anhang
Kürzung