Bevor wir über OO, Entwurfsmuster und die vielen objektorientierten Prinzipien sprechen, sollten wir zunächst eines beherrschen: die Kapselung. Wenn Sie die Prinzipien und Techniken der Kapselung beherrschen, können Sie ein Programm mit einem schönen Framework erstellen, auch wenn Sie keine OO-Sprache verwenden. Die Anwendung dieser Prinzipien außerhalb von Programmen kann auch überraschende Ergebnisse hervorbringen. „Design Rules – The Power of Modularity“ (http://www.douban.com/subject/1737636/) stellt Kapselung und Modularität auf ein Podest, und sie verdienen diese Position. Dies ist die grundlegendste Methode (keine andere), die wir zur Lösung von Komplexitätsproblemen verwenden. Ein Programm ist ein komplexes System. „Tao zeugt eins, eins zeugt zwei, zwei zeugt drei, drei zeugt (vier, vier zeugt ...) alle Dinge.“ Wenn die Quelle der Komplexität als die Transformation des „Tao“ betrachtet wird, dann muss diese „Eine“ eine Kapselung sein. An der „zweiten“ Stelle stehen unterschiedliche Programmiersprachen und die aus diesen Programmiersprachen abgeleiteten Methoden, wie etwa das OO-Design-Paradigma, das FP-Paradigma (Funktionale Programmierung), das Schichtungsprinzip und so weiter. An der „dritten“ Stelle stehen OO-Designprinzipien, etwa das Liskovsche Substitutionsprinzip oder der Vorrang der Komposition vor der Vererbung, während an der „vierten“ Stelle nach der „dritten“ Stelle spezifische Designmuster und dergleichen stehen. Ich bin dumm und kann mich immer noch nicht an diese Prinzipien erinnern, beispielsweise was das Liskovsche Substitutionsprinzip ist und wie dieses oder jenes Modell implementiert wird. Unter den Entwurfsmustern interessiere ich mich nur für das Strategiemuster und habe wenig Interesse an anderen Mustern. Im Wesentlichen bieten uns diese Muster oder Prinzipien nur eine Methode und ein Werkzeug, um die Kapselung besser zu implementieren. Kopieren und Einfügen ist der Feind der Kapselung und der größte Verursacher von hässlichem Code. Einmaliges Kopieren entspricht dem Hinzufügen von mindestens einem variablen Punkt, und zweimaliges Kopieren entspricht dem Hinzufügen von mindestens zwei variablen Punkten. Warum sagen wir „zumindest“? Da es Verknüpfungen zwischen Modulen gibt, führen Änderungen an einer Stelle auch zu Änderungen an mehreren anderen Stellen. Wenn wir annehmen, dass S das System selbst, M eine Messung des Systems selbst und C die durchschnittliche Anzahl der Kopien des Moduls im System S (C>1) ist, dann sollte die Beziehung zwischen M und C eine exponentielle Beziehung sein: M ist proportional zu C hoch N (N>1). Die exponentielle Beziehung ist schon beängstigend genug, aber noch beängstigender ist, dass wir bei der Änderung eines Moduls im System, wenn das Modul mehrere Kopien im System hat, möglicherweise zu faul sind und nur eine der Kopien ändern, anstatt alle zu ändern. Dies führt zur Aufspaltung des Moduls, von einem Modul in mehrere ähnliche, aber unterschiedliche Module, was die Komplexität des Systems enorm erhöht und letztendlich zum Verfall des Systems führt. Intuitiv ist die Komplexität eines schlecht konzipierten Systems ungefähr eine faktorielle Beziehung oder sogar eine Potenzbeziehung der Anzahl der Module, was eine noch erschreckendere Beziehung ist als eine Exponentialbeziehung. Daher ist Kopieren und Einfügen eine sehr böse Art der Codierung. Beim Codieren müssen Sie Wege finden, das Kopieren und Einfügen zu reduzieren. Dies sollte eher während der Codierung berücksichtigt werden und nicht während der Refactoring-Phase erledigt werden. Welche Methode, Mittel und Modelle zum Einsatz kommen, ist eine Frage des Details. Wenn Sie darauf bestehen, nicht zu kopieren und einzufügen, und dabei bleiben, werden die Vorteile enorm sein und der von Ihnen geschriebene Code wird von hoher Qualität und hohem Wert sein. Wenn ich die Systeme anderer sehe, kann ich sofort erkennen, was die Vor- und Nachteile dieses Systems sind. Seien es Entwurfsmuster, Orthogonalität von Schnittstellen oder Entwurfsprinzipien – vielleicht haben Sie sich nie bewusst damit befasst, doch am Ende werden Sie feststellen, dass sie alle zum selben Ziel führen, und Sie spüren eine Verbundenheit mit den ausländischen Experten. Wir werden die Ideen und Methoden dieser Experten spontan kombinieren und verbessern und sogar neue Methoden und Mittel schaffen. Beginnen Sie direkt bei eins, aus eins wird zwei, aus zwei wird drei, aus zwei wird vier, anstatt die drei und die vier auf dogmatische und ehrfürchtige Weise zu lernen. Vielleicht haben Sie zu diesem Zeitpunkt vergessen, was ein Objekt ist. Der Grund, warum ich mich beschwere, ist, dass ich von gestern auf heute ein Modul umgestalte. Die Kernkomponente dieses Moduls M1 ist ein aus RTF gepackter Layoutregel-Editor. Der Typ, der diese Kernkomponente entworfen hat, hat ein Steuerelement A mit RichTextBox als Mittelpunkt entworfen und dann etwas Regellogik dieses Steuerelements extrahiert und sie in die statischen Methoden der Klasse B und Klasse C eingefügt. Noch erstaunlicher ist, dass sich Klasse B in einem anderen Modul M2 befindet, während sich Klasse C in Modul M1 befindet. Dieses Steuerelement wird an drei Stellen in M1 verwendet: D, E und F. Jedes von D, E und F muss sieben oder acht Ereignisse für diesen Bereich A registrieren und dann die statische Methode der Klasse B im Modul M2 und die statische Methode der Klasse C im Modul M1 in der Ereignisrückruffunktion aufrufen, um eine Logik zu implementieren. Jetzt möchte ich ein Steuerelement G schreiben, und dieses G benötigt auch ein Steuerelement A. In diesem Fall muss ich eine Reihe von A-Ereignissen und Rückruffunktionen für G registrieren und dann eine Menge Logik in die Rückruffunktion einfügen, was mindestens 200 Codezeilen in Anspruch nehmen wird. Um diese Rückruffunktionen zu schreiben, muss ich die internen Betriebsmechanismen der Steuerung A und der Klassen B und C verstehen. Mit anderen Worten: Um Schweinefleisch zu essen, müssen Sie das Schwein selbst töten. Natürlich können Sie den Code auch aus D, E oder F kopieren und zeitsparend abändern. Das schwerwiegende Problem besteht darin, dass Steuerung A selbst logische Fehler und fehlerhafte Funktionen aufweist und repariert werden muss. Da es überall repliziert wird, wirkt sich eine Bewegung auf den gesamten Körper aus. Wenn Sie A operieren, müssen Sie auch B, C, D, E und F operieren. Als ich die Operation an A durchführte, um sie zu kompilieren, kommentierte ich alle Codes, die sich auf A in B, C, D, E und F beziehen, und kommentierte insgesamt etwa 1.500 Codezeilen. Tatsächlich gibt es in diesen 1500 Codezeilen nur etwa 200 Zeilen wirklich wertvollen Code, und der restliche Code wird komplett durch Kopieren, Einfügen und Ändern des Variablennamens vervollständigt. Warum tritt dieses Problem auf? Wegen Kopieren und Einfügen. Kopieren und Einfügen ist ganz einfach. Sie können einfach ein paar Wörter kopieren, ändern und verwenden, ohne sich Gedanken über die Verpackung machen zu müssen. Tatsächlich müssen Sie 200 bis 300 Zeilen Code schreiben, um auf das Steuerelement A zu verweisen. Wenn Sie an mehreren Stellen darauf verweisen, müssen Sie mehr als 1.000 Zeilen Code schreiben. Kopieren und Einfügen ist kein Problem, aber wenn Sie feststellen, dass A einen Fehler enthält oder erweitert werden muss, müssen Sie beim Ändern von A auch diese 1.000 Zeilen Code verschieben. Diese 1.000 Zeilen Code können weiteren Code beinhalten, was letztendlich dazu führt, dass Sie weiteren Code ändern müssen. Das ist Code-Rot. Tatsächlich ist dieses A sehr gut gekapselt. Es erfordert nicht, dass andere Klassen Eingabedaten eingeben. Andere Klassen müssen lediglich ein endgültiges Regelergebnis, eine Liste, vom A-Steuerelement abrufen. Bei einer guten Kapselung lassen sich A aufrufen und das Ergebnis mit zwei bis drei Codezeilen erhalten. Der Grund für die fehlende Kapselung liegt darin, dass wir entweder an das Kopieren und Einfügen gewöhnt sind, zu faul zum Kapseln sind oder überhaupt keine Ahnung vom Kapseln haben. Viele neue oder nicht ganz so neue Programmierer, insbesondere Webentwicklungsprogrammierer, beschweren sich immer über den geringen technischen Inhalt ihrer Arbeit und möchten immer mehr lernen. Im Wesentlichen ist die Arbeit, die sie machen, sehr technisch, es hängt alles davon ab, wie man es betrachtet. Wenn Sie Ihre Arbeit nur als einfaches Kopieren, Einfügen, Plagiat und Codeänderung betrachten, ist der technische Inhalt natürlich gering. Wenn Sie Ihren Job darin sehen, das Kopieren und Einfügen zu vermeiden, die Qualität und den Fortschritt zu verbessern, unnötige Dinge bei der Arbeit zu eliminieren und jede Art von Verschwendung zu vermeiden, dann ist der technische Inhalt dieses Jobs extrem hoch. Beten Sie den Meister nicht an. Wenn Sie das tun, erledigen Sie die Arbeit des Meisters. Beten Sie nicht zu neuen Technologien. Wenn Sie das tun, könnte Ihr Job der Embryo einer neuen Technologiegeneration sein. Jedes Stück, jede Farbe und jeder Duft, alles ist in meinem Herzen. Der grüne Bambus ist ganz Dharmakaya und die üppigen gelben Blumen sind ganz Prajna. |
>>: Entwicklungsdetails von Vue3-Komponenten
Brotli ist ein neues Datenformat, das eine um 20 ...
Die Verwendung von Schriftarten im Web ist sowohl ...
Der Wachstumspfad vom Linux-Neuling zum Linux-Mei...
Ich habe einen falschen MySQL-Befehl eingegeben u...
Inhaltsverzeichnis 1. Ändern Sie den Port 2375 vo...
Laden Sie zuerst das komprimierte Nacos-Paket von...
Obwohl die papierlose Welt noch nicht angebrochen...
Inhaltsverzeichnis Ziehen Sie ein CentOS-Image Ge...
Inhaltsverzeichnis Umfeld Installieren Sie CentOS...
1. Über den Dateiserver Wenn Sie in einem Projekt...
In diesem Artikelbeispiel wird der spezifische Co...
Laden Sie zunächst die Zip-Archivversion von der ...
Einführung Mit EXISTS wird geprüft, ob eine Unter...
<br />Dies ist nicht nur ein Zeitalter der I...
Nginx verbirgt die Versionsnummer In einer Produk...