Wenn Sie sich später den Code ansehen, den Sie geschrieben haben, werden Sie dann verwirrt sein?

Viele Programmierer wissen nicht, wie man Code organisiert, wie man die Effizienz verbessert, wie man die Wartbarkeit, Wiederverwendbarkeit, Skalierbarkeit und Flexibilität des Codes verbessert. Der Code, den sie schreiben, ist ein Durcheinander, aber solch ein Durcheinander an Code kann tatsächlich normal ausgeführt werden . .

Kommt Ihnen diese Codierungserfahrung bekannt vor?

Viele Programmierer um mich herum werden eine solche Erfahrung machen, wenn ich mir nach anderthalb Jahren den Code ansehe, den ich geschrieben habe Sehr seltsam. Ich war überrascht und dachte, wurde so ein schlechter Code schon einmal von mir geschrieben? Ich kann tatsächlich so einen schlechten Code schreiben!

Was den Code betrifft, der derzeit noch gepflegt wird, Es wird ein Gedanke auftauchen, die Idee umzugestalten, oder es gibt vielleicht einen besseren Weg, sie umzusetzen. Zu diesem Zeitpunkt hat Ihre Hassliebe zum Code bereits begonnen ...

Dieser Film beginnt hauptsächlich mit den sechs Grundprinzipien. Als Einführung in das Entwurfsmuster beschreibt er die Beziehung zwischen den sechs Grundprinzipien und das Entwurfsmuster. Es werden die Entwurfsmuster nacheinander vorgestellt und die Entwurfsmuster und die tägliche Entwicklung detailliert beschrieben.

Grundlegende Spezifikationen und Einschränkungen

Für grundlegende Spezifikationen und Einschränkungen glaube ich, dass jedes qualifizierte Team seine eigenen Dinge haben wird. Einerseits vereinheitlicht es Standards und erhöht die Lesbarkeit und Wartbarkeit. Andererseits erleichtert es auch das Auftreten von Fehlern nach dem Ausscheiden aus dem Unternehmen und Neulinge können Probleme schneller lokalisieren und lösen.

Der chaotische Code implementiert eine große Funktion. Damit Nachzügler ihn beibehalten, werden sie zweifellos alle Vorfahren herzlich begrüßen. Eine gute Programmiergewohnheit gehört zur Selbstkultivierung eines qualifizierten Programmierers. Sie ist für sich selbst und andere von Vorteil, ohne Schaden zu nehmen.

Bei Spezifikationen und Einschränkungen in der Entwicklung ist zunächst die Benennung zu sagen.

In den letzten fünf Jahren meiner Arbeit habe ich mit den unterschiedlichsten Menschen zusammengearbeitet. Ich erinnere mich höchstens daran, dass ich in meiner Freizeit auch mit fünf Projekten zusammengearbeitet habe Mit verschiedenen Helden gemeinsam zu lernen und Fortschritte zu machen, ist für mich die unregelmäßige Benennung das Schwierigste.

Es gibt viele nicht standardmäßige Stile mit allen möglichen seltsamen Namen. Ich habe eine solche Namensliste gesehen, eine heißt Spaltendetails und die andere heißt Spaltennachrichten. Die Namen sind „ZhuanLaiDetalActivity“ und „ZhuanLaiLiuYanActivity“, was mich verwirrt.

Haben Sie keine Angst vor einem solchen Namen? Wenn Sie Angst vor einem solchen Namen haben, können Sie sich zumindest eine ungefähre Vorstellung davon machen Davon habe ich einige Abkürzungen des chinesischen Pinyin gesehen, zum Beispiel heißt das Tierkontrollzertifikat „djz“, und dieses scheint noch verwirrender zu sein.

Was die Pinyin-Benennung betrifft, weiß ich nicht, ob ich kritisiert werde, wenn ich sie hier erwähne. Ich habe einige Freunde getroffen, die es immer mögen, Hanyu zu fördern. Pinyin ist eine großartige Initiative der chinesischen Nation Chinesische Kultur, aber wenn ich Pinyin programmiere, fühle ich mich wirklich schlecht.

Selbst mit der Unterstützung der leistungsstärksten Technologie sieht der Code, den ich schreibe, wie die Arbeit eines Grundschülers aus. Ich möchte hier nicht auf das chinesische Pinyin herabschauen, ich drücke nur einige meiner inneren Gedanken aus .

Empfehlung: Benennung mit großem Buckel, kleinem Buckel oder Unterstrich ist akzeptabel. Wenn es keinen einheitlichen Standard gibt, können Sie auf das „Alibaba Java Development Manual“ zurückgreifen. Für Freunde, die gerade erst in die Branche eingestiegen sind mit der Namensgebung wird eine große Hilfe für zukünftiges Wachstum sein.

Download-Adresse des Entwicklungshandbuchs: https://pan.baidu.com/s/1mjZxvSW.

Eine weitere hervorzuhebende Sache ist die Anmerkung. Viele Leute denken vielleicht, je mehr Kommentare, desto besser. Ich habe schon früher Bücher gesehen, die das Hinzufügen weiterer Kommentare befürworten, aber ich denke, dass Kommentare manchmal eine große Belastung und Missverständnisse darstellen.

Bei meiner letzten Überprüfung habe ich festgestellt, dass einige Kollegen, als sie einen Teil meines Codes kopierten, tatsächlich eine andere Funktion erstellen wollten. Sie wollten nur etwas Code kopieren und größere Änderungen vornehmen (ich erfinde nicht gerne neu). das Rad, daher ist es für einige ähnliche Funktionen am besten, sie flexibler zu gestalten, um die Wiederverwendbarkeit und Flexibilität des Codes zu verbessern.

Tatsächlich gibt es nur sehr wenige Stellen, die wiederverwendet werden können. Ich verstehe nicht, warum ich selbst ein paar Zeilen Code schreibe Ich habe auch meine Notizen und den Autor kopiert. Als ich diesen Kurs betrat, ging ich zu Git, um die historischen Beiträge zu überprüfen, und die funktionale Beschreibung war für diesen Kurs völlig irrelevant ...

Zu den Kommentaren gibt es noch etwas zu sagen: Bei guten Benennungsstandards können viele unnötige Kommentare weggelassen werden B. Login und Registrierung, sowie Login- und Registrierungskommentare, die völlig unnötig sind.

Gute Gewohnheiten können unserer Entwicklung viel Komfort bringen, aber manche Leute nennen sie gerne Textansicht1 und Textansicht2. Auch wenn sie unten verwendet werden, handelt es sich immer noch um eine Gruppe laufender Alpakas . Die Art, die auf und ab rauscht.

1.for (int i = 0; i

2. // TODO

3 }

Für Viele Leute denken vielleicht, dass diese Art von Code normal ist, und einige Leute geben vielleicht Lehrer Tan Haoqiang die Schuld. Ja, es gibt tatsächlich viele Probleme in Tan Haoqiangs Buch, aber das ist nicht der Grund, diesen Code zu schreiben.

In der täglichen Entwicklung debuggen Sie immer die for-Anweisung, selbst wenn Sie Kommentare hinzufügen.

Da jedes Team seine eigenen Normen und Einschränkungen hat, werden in Zukunft auch verschiedene Sprachen unterschiedliche Einschränkungen haben Ich werde einen speziellen Blogbeitrag mit detaillierten Einschränkungen und Spezifikationen schreiben.

In diesem Bereich gibt es wirklich viele Dinge, über die ich schreiben möchte, wie zum Beispiel die wahllose Verwendung der Fälle 1, 2 und 3, die immer verwirrend sind, wie zum Beispiel notwendige konstante Substitutionsvariablen, wie zum Beispiel Thread-Pools Ersetzen von Threads, z. B. Verwenden von Singletons bei Bedarf. Es gibt so viele Dinge, dass ich heute nicht auf zwei wichtige Punkte eingehen werde: Benennung und Annotation.

Empfehlung: Verwenden Sie Kommentare rational, wenn Sie unbekannten Code und unklare Logik lernen, verwenden Sie so viele Kommentare wie möglich, um das Verständnis zu erleichtern.

Die Wirkung von Kommentaren wird durch die Benennung erreicht, aber wenn die Logik komplex ist oder zu viele Betriebszustände vorliegen, sind notwendige Kommentare dennoch sehr wichtig, um die Wartungskosten zu senken.

Einige Programmierideen, mit denen Sie vertraut sein sollten

Die Zeit, die ein Programmierer mit dem Schreiben von Programmen verbringt, macht wahrscheinlich 10–20 % seiner Arbeitszeit aus. Die meisten Programmierer können etwa 10–12 Zeilen Code schreiben das wird es in das Endprodukt schaffen – egal wie technisch versiert die Person ist.

Gute Programmierer verbringen 90 % ihrer Zeit mit Nachdenken, Recherchieren und Experimentieren, um die optimale Lösung zu finden. Schlechte Programmierer verbringen 90 % ihrer Zeit damit, problematische Programme zu debuggen und Programme blind zu ändern, in der Hoffnung, dass eine bestimmte Schreibweise funktioniert.

Für einen guten Programmierer ist die Logik das Wichtigste. Er ist bereit, mehr Zeit mit dem Nachdenken zu verbringen. Dadurch treten weniger Fehler auf und die Fehlerrate kann sogar auf ein sehr niedriges Niveau gesenkt werden.

Ich bin kein sehr guter Entwickler, aber ich habe im Laufe der Jahre immer noch diese Angewohnheit. Bei komplexen oder vielfältigen Funktionen kläre ich immer zuerst die Vorgänge und Fehler auf Minenfelder Ich sage meinen Teamkollegen oft, dass ein Bild mehr sagt als tausend Worte. Wenn man seine Gedanken vorher klarstellt, erhält man mit halbem Aufwand das Doppelte.

Egal, ob die Geschäftslogik komplex ist oder nicht, machen Sie es einfach. Wenn Sie etwas finden, das nicht stimmt, werden Sie es hinzufügen Der Code stapelt sich dort immer wieder. Die Änderungen haben sich bis zur Unkenntlichkeit verändert, und für die Wartungsleute ist es noch schlimmer.

Hier schlägt der Autor auch vor, dass Leser genauso gut zuerst zeichnen können, ein Modul weiterhin in Schnittstellen zerlegen und das Modul durch Implementieren der Schnittstelle implementieren, um eine schnittstellenorientierte Programmierung zu erreichen Die Wartbarkeit wird erheblich verbessert...

Für die Kommunikation zwischen Modulen sollte es nicht um die Assoziation zwischen Klassen gehen, sondern um die Interaktion durch Abstraktion zu erreichen, sollte man sich nicht auf Details verlassen. Das ist etwas kompliziert, um es ganz klar auszudrücken: Es handelt sich eher um eine schnittstellenorientierte Programmierung als um eine umsetzungsorientierte Programmierung.

Der Vorteil davon besteht darin, dass Sie, wenn Sie die aufgerufene Klasse in Zukunft durch eine andere Implementierungsklasse ersetzen möchten, nicht die Klassen, die sie aufgerufen haben, einzeln ändern müssen, da sie sich anpassen Schnittstelle hat sich nicht geändert. Wenn Sie die Implementierungsklasse der Schnittstelle durch eine neue Klasse in der Konfiguration ersetzen, wird alles ersetzt.

Je schwächer die Kopplung zwischen Klassen ist, desto günstiger ist die Wiederverwendung. Wenn eine schwach gekoppelte Klasse geändert wird, hat dies keine Auswirkungen auf verwandte Klassen.

Vorschlag: Machen Sie Ihren Kopf frei, bevor Sie beginnen. Mit halbem Aufwand erzielen Sie das doppelte Ergebnis. Während des Entwicklungsprozesses können Sie genauso gut zuerst die Schnittstelle definieren und die Modulentwicklung abschließen, indem Sie die Schnittstelle implementieren, um die Fehlerrate so weit wie möglich zu reduzieren und besseren Code zu schreiben.

Die Verbesserung der technischen Fähigkeiten spiegelt sich hauptsächlich im Code „hohe Kohäsion und geringe Kopplung“ wider, da diese Ideen viele Entwicklungsmodelle abgeleitet haben, wie zum Beispiel das mittlerweile beliebte MVC, MVP, MVVM usw.

Versionsiteration und -rekonstruktion

Wenn wir ein System erstellen, sollten wir nicht erwarten, dass die Systemanforderungen zu Beginn festgelegt werden und sich nie wieder ändern. Die Idee Da sich die Anforderungen zwangsläufig ändern, besteht die Frage, wie die Entwurfssoftware relativ einfach geändert werden kann, wenn sich die Anforderungen ändern, sodass bei neuen Anforderungen das gesamte Programm gestürzt und neu gestartet werden muss.

Ich glaube, dass viele Freunde darauf gestoßen sind, was nach N-Iterationen und Modifikationen zu einer riesigen Funktion geworden ist Immer größer wird ein Teufelskreis, und das Refactoring von Code geht bald in die Geschichte ein.

Es ist unbestreitbar, dass die Rekonstruktion aus Sicht der Wartungskosten tatsächlich eine sehr gute Lösung ist. Die Kosten für die Rekonstruktion sind niedriger als die Kosten der ursprünglichen Grundwartung und auch für zukünftige Wartungsarbeiten bequemer. Einige Unternehmen drängen sogar das gesamte Projekt nach mehreren Versionsiterationen direkt zur Rekonstruktion. So etwas kommt nicht nur in kleinen Unternehmen vor, sondern kommt auch in einigen großen Unternehmen häufig vor.

Technisch gesehen gibt es beim Refactoring von komplexem Code drei Dinge zu tun: den alten Code verstehen, den alten Code zerlegen und neuen Code erstellen.

Der alte Code, der umgestaltet werden muss, ist oft schwer zu verstehen, insbesondere in Modulen, die mehrere Iterationen haben und von vielen Leuten gehandhabt werden; eine übermäßige Kopplung zwischen Modulen führt dazu, dass sich eine einzige Bewegung auf den gesamten Körper auswirkt, was die Kontrolle erschwert der Einflussbereich; alter Code ist nicht einfach zu testen. Es gibt keine Garantie dafür, dass neuer Code korrekt ist, insbesondere wenn die Produktdokumentation unvollständig ist.

Dies ist ein Code, den ich während der letzten Überprüfung gefunden habe. Ganz zu schweigen von der unregelmäßigen Verwendung von Konstanten. Dies ist das Ergebnis von Produktiterationen, aber dies ist kein Fehler Entschuldigung, nachdem ich das Rad so oft gebaut habe, sollte es wirklich nicht sein. Als negatives Lehrmaterial für die Wiederverwendbarkeit von Code wird es hier anschaulich widergespiegelt. Wenn es mehr Zustände gibt, wird dies zwangsläufig viele Male wiederholt ...

Vorschlag: Refactoring ist nicht allmächtig, Refactoring Nachdem der Code geändert wurde In mehreren nachfolgenden Versionen wurde der Code unordentlich und unorganisiert, und das Durcheinander des Codes wiederholte sich immer wieder.

Da wir nicht sicher sein können, ob sich die Anforderungen in Zukunft ändern werden, können wir damit nur umgehen, indem wir die Codequalität verbessern, uns auf die gleiche Weise an Änderungen anpassen, Schnittstellen vernünftig gestalten und jedes Mal mehr darüber nachdenken Wenn sich die Anforderungen ändern, wird der Code gekapselt und extrahiert und die vorhandene Logik wird so wenig wie möglich geändert.

Die Bedeutung von Entwurfsmustern

Diejenigen, die wissen, wie man entwirft, sind Bauingenieure, und diejenigen, die nicht wissen, wie man entwirft, sind diejenigen, die Steine ​​bewegen.

Ich habe schon viel gesagt. Lassen Sie uns jetzt direkt über die Bedeutung von Designmustern sprechen. Wenn es um Designmuster geht, müssen wir die sechs Grundprinzipien und das architektonische Design erwähnen Bedeutung von Designmustern Sie können sich vorstellen.

Erstens sind die sechs Grundprinzipien immer noch etwas umstritten. In den Büchern, die ich zuvor gelesen habe, handelt es sich im Allgemeinen um das Prinzip der Einzelverantwortung, das Demeter-Gesetz, das Richter-Substitutionsprinzip, das Eröffnungs- und Schlussprinzip und die Abhängigkeitsumkehr Prinzip und Schnittstellenisolationsprinzip.

Aber ich habe kürzlich in einigen Beiträgen gesehen, dass es ein Sprichwort gibt, dass es kein Prinzip der Schnittstellenisolation gibt, sondern das Prinzip der Synthese/Aggregation-Wiederverwendung. Um die vorherigen Vorbereitungen nicht zu beeinträchtigen, wird das Prinzip der Synthese/Aggregation-Wiederverwendung gelten separat genommen werden. Kommen Sie heraus und sagen Sie es.

Sechs Grundprinzipien, die die Seele des gesamten Architekturdesigns und eine Leitideologie des Architekturdesigns sind, während Designmuster eine spezifische Designtechnik des Architekturdesigns sind die spezifische Praxis des architektonischen Entwurfs.

Beginnen wir mit dem Architekturdesign. Architekturdesign spiegelt sich hauptsächlich in den Abstraktionsfähigkeiten wider. Die Abstraktionsfähigkeiten hängen von der Programmiererfahrung, der funktionalen Demontage und dem Verständnis sowie der logischen Genauigkeit ab.

Beim Architekturdesign sollten Sie das Problem so umfassend wie möglich berücksichtigen und den Code so umfassend wie möglich gestalten. Dies ist die Grundvoraussetzung, die Architekturdesigner haben sollten.

Je umfassender und inklusiver die betrachteten Themen sind, desto schwieriger wird die Arbeit und desto mehr Hindernisse werden für einen selbst geschaffen. Abstrahieren Sie diese detaillierten Probleme angemessen und schlagen Sie Lösungen vor. Je höher der Abstraktionsgrad, desto vernünftiger ist die Lösung. Dies ist der Wert des Architekten.

Von spezifischen Anforderungen über die Code-Implementierung bis hin zu spezifischen Produkten. Der Zweck des Architekturdesigns ist nichts anderes als die Wiederverwendbarkeit, Skalierbarkeit und Stabilität des Systems. Bestimmte Dinge können diese Eigenschaften nicht gut widerspiegeln.

Im Prozess des Architekturdesigns sagt uns das Prinzip der Einzelverantwortung, dass wir eine hohe Kohäsion und eine geringe Kopplung besser berücksichtigen sollten. Diese Klasse wird für Datenanforderungen verwendet, daher sollten einige Methoden nicht zum Parsen von JSON verwendet werden Diese Klasse wird zum Laden von Bildern verwendet. Bitte isolieren Sie die Anmerkungen der Ansicht, sodass eine Klasse nur für eine Verantwortung verantwortlich ist und nur einen Grund für Änderungen hat.

Wenn eine Klasse mehr Verantwortlichkeiten übernimmt, bedeutet dies, dass diese Verantwortlichkeiten miteinander verknüpft werden, was zu unnötigen Wartungskosten führt. Aus einer großen Perspektive sind die MVP- und MVC-Muster beide Verkörperungen des Single-Responsibility-Prinzips. Modell, Ansicht und Kontrolle sind isoliert und erfüllen jeweils ihre eigenen Aufgaben.

Demeters Gesetz weist uns darauf hin, dass, wenn zwei Klassen nicht direkt miteinander kommunizieren müssen, die beiden Klassen auch nicht direkt interagieren sollten. Wenn eine Klasse eine Methode einer anderen Klasse aufrufen muss, kann der Aufruf über einen Dritten weitergeleitet werden.

Je schwächer die Kopplung zwischen Klassen, desto einfacher ist die Wiederverwendung. Wenn eine schwach gekoppelte Klasse geändert wird, hat dies keine Auswirkungen auf verwandte Klassen. Der Schwerpunkt liegt auf der losen Kopplung zwischen Klassen.

Was das Liskov-Substitutionsprinzip betrifft, haben viele Leute vielleicht noch nichts von diesem Begriff gehört, aber er wird im eigentlichen Entwicklungsprozess ständig verwendet. Tatsächlich ist es sehr einfach, Subtypen zu ersetzen ihre übergeordneten Typen.

Nehmen Sie ein einfaches Beispiel: „List list = new ArrayList();“. Der Vorteil dieser Vorgehensweise ist eigentlich sehr einfach, eines Tages kann ArrayList die Nachfrage nicht erfüllen Sie müssen stattdessen LinkedList verwenden. Sie müssen lediglich ArrayList durch LinkedList ersetzen, anstatt das globale Listenobjekt zu ändern, was die Wartbarkeit verbessert.

Das Öffnungs- und Schließprinzip ist der Kern des objektorientierten Prinzips. Es besteht aus zwei Teilen, offen für Erweiterung und geschlossen für Modifikation. Softwareanforderungen ändern sich ständig. Für Softwareentwickler ist es notwendig, eine flexible Systemerweiterung zu erreichen, ohne das ursprüngliche System zu ändern.

Offenheit für Erweiterungen bedeutet abstrakte Programmierung, nicht konkrete Programmierung, da die Abstraktion relativ stabil ist. Erweiterungen werden durch Schnittstellen oder abstrakte Klassen eingeschränkt, und es werden keine Grenzen für Erweiterungen definiert, die in Schnittstellen oder abstrakten Klassen nicht vorhanden sind erscheinen dürfen.

Lassen Sie die Klasse von einer festen Abstraktion abhängen, sodass sie für Änderungen gesperrt ist. Dies basiert auf Vererbung und Polymorphismus, die die Vererbung abstrakter Klassen implementieren und Methoden durch Überschreiben ihrer Methoden erweitern können.

Das Prinzip der Abhängigkeitsinversion bezieht sich auf die Abstraktion und nicht auf die spezifische Implementierung. Tatsächlich handelt es sich um eine schnittstellenorientierte Programmierung und nicht um eine umsetzungsorientierte Programmierung Kopplung zu lösen.

Im Allgemeinen ist die Wahrscheinlichkeit einer Abstraktionsänderung sehr gering, sodass Benutzerprogramme von der Abstraktion abhängig sind und auch Implementierungsdetails von der Abstraktion abhängen. Auch wenn sich die Implementierungsdetails weiterhin ändern, muss sich das Client-Programm nicht ändern, solange die Abstraktion unverändert bleibt. Dadurch wird die Kopplung von Clientprogrammen an Implementierungsdetails erheblich reduziert.

Das Schnittstellenisolationsprinzip besagt: „Es ist besser, mehrere spezialisierte Schnittstellen zu verwenden als eine einzelne Schnittstelle.“

Ein Modul sollte sich auf die benötigten Schnittstellen verlassen, alle benötigten Schnittstellen bereitstellen und unnötige Schnittstellen eliminieren. Gleichzeitig sollte es dem Prinzip der Einzelverantwortung folgen, um die durch Aufblähung verursachte Verschmutzung zu vermeiden Schnittstellen werden zu einer aufgeblähten großen Schnittstelle zusammengeführt, was eine Art Verschmutzung der Schnittstelle darstellt.

Die Granularität der Schnittstelle darf nicht zu klein sein, was für Entwickler ungünstig ist Reduzierte und maßgeschneiderte Dienste können nicht bereitgestellt werden, was zu Problemen für das Gesamtprojekt führt. Unvorhersehbare Risiken und ein angemessenes Schnittstellendesign sind ebenfalls eine Kunst.

Über dieses Bild muss es viele Kontroversen geben, da viele Designmuster mehrere Grundprinzipien verwenden. Das obige Bild ist nur eine grobe Zusammenfassung der Designmuster.

Betont die spezifische Verkörperung der sechs Grundprinzipien (einschließlich des Prinzips der Synthese/Aggregation und Wiederverwendung) im Entwurfsmuster. Außerdem wird erläutert, dass die sechs Grundprinzipien und die 23 Entwurfsmuster einander ergänzen. Die sechs Grundprinzipien dienen als Eckpfeiler und Vorlage für Designmuster. Designmuster sind eine flexible Manifestation der Anwendung von sechs Grundprinzipien.

Das Prinzip der Synthese/Aggregation und Wiederverwendung ist etwas umstritten. Derzeit behalten einige Bücher das Prinzip der Wiederverwendung von Komposition/Aggregation bei und entfernen das Prinzip der Schnittstellenisolation. Das Prinzip der Wiederverwendung von Komposition/Aggregation bezieht sich auf die Implementierung einer geringeren Nutzung von Vererbung und einer stärkeren Nutzung von Kompositionsbeziehungen.

Zusammensetzung und Aggregation sind beide Arten von Objektmodellierungsbeziehungen. Die Aggregation stellt eine schwache Eigentumsbeziehung dar. Das Ganze besteht aus Teilen, und der Teil kann als unabhängiges Individuum existieren, ohne vom Ganzen getrennt zu sein Art der Assoziationsbeziehung Eine starke Eigentumsbeziehung spiegelt die strikte Beziehung zwischen dem Teil und dem Ganzen wider. Der Lebenszyklus des Teils und des Ganzen ist konsistent und der Teil kann nicht vom Ganzen getrennt werden.

Zusammenfassung: Die sechs Grundprinzipien sind die Verkörperung des objektorientierten Denkens. Das Prinzip der Einzelverantwortung und das Prinzip der Schnittstellenisolation verkörpern die Idee der Kapselung Das Abschlussprinzip verkörpert die Kapselung und Kapselung von Objekten und das Liskov-Substitutionsprinzip ist die Norm für die Objektvererbung.

Das Abhängigkeitsinversionsprinzip ist die Verkörperung von Polymorphismus und abstraktem Denken. Auf der Grundlage eines vollständigen Verständnisses der Objektorientierung, der Beherrschung grundlegender Designprinzipien und der Fähigkeit, diese flexibel im Projektdesign zu verwenden, können wir unsere Codequalität und unser Strukturdesign verbessern.

Vor allem, um Wiederverwendbarkeit, Wartbarkeit, Skalierbarkeit und Flexibilität sicherzustellen, was ebenfalls notwendige Kenntnisse zum Verstehen und Beherrschen von Entwurfsmustern sind.

Ergänzung

In Bezug auf die sechs Grundprinzipien sollte unsere Entwicklung diese im Auge behalten und sie flexibel in der täglichen Entwicklung anwenden Das, was zu dir passt, ist das Beste.

Wenn ein Modul zu diesem Zeitpunkt sehr leichtgewichtig ist und Entwurfsmuster nur um der Verwendung von Entwurfsmustern willen verwendet, wird dies zweifellos unscheinbar erscheinen, das Projekt aufblähen lassen und auch einige unnötige Wartungskosten mit sich bringen (obwohl die Wartung Kosten sind gering).

Ich habe vor kurzem damit begonnen, Informationen zu organisieren und mich darauf vorzubereiten, ein spezielles Thema zu Designmustern zu schreiben, wobei ich mich hauptsächlich auf MVP-Fallstricke und Dimits Gesetz, Framework und Öffnungs- und Schließprinzipien, Singletons und Fallstricke, Skinning und Beobachtermodus, Laden konzentriere Listen und Vorlagenmethodenmuster, der Vergleich zwischen Konstruktoren und Buildern, mehrere Anmeldungen von Drittanbietern und Befehlsmuster werden in Zukunft weiter verbessert, also bleiben Sie dran.