Einführung in objektorientierte Prinzipien in PHP

Es ist sehr schwierig, Software sehr flexibel und wartungsfreundlich zu gestalten. Flexible Software ist komplex aufgebaut und schwer zu warten. Es gibt Gewinne und Verluste, und der Schlüssel liegt darin, wie man mit beiden umgeht, sodass die Verluste die Verluste überwiegen. Das Design und die Entwicklung von Software sollten den folgenden sechs Prinzipien folgen:
1. OCP
Vollständiger Name: „Open-Closed-Prinzip“ Open-Closed-Prinzip
Beschreibung: Offen für Erweiterung, wegen Änderung geschlossen.
Vorteile: Das nach den OCP-Prinzipien konzipierte System reduziert die Kopplung zwischen verschiedenen Programmteilen und ist relativ gut anpassbar, flexibel und stabil. Wenn einem vorhandenen Softwaresystem neue Funktionen hinzugefügt werden müssen, muss die Abstraktionsschicht, die die Basis des Systems darstellt, nicht geändert werden. Es müssen lediglich neue Module zur ursprünglichen Basis hinzugefügt werden, um die hinzuzufügenden Funktionen zu realisieren . Die hinzugefügten neuen Module haben keine oder nur sehr geringe Auswirkungen auf die Originalmodule, sodass kein erneuter Test der Originalmodule erforderlich ist.
So implementieren Sie das „Offen-Geschlossen“-Prinzip
Beim objektorientierten Design darf sich die Abstraktionsschicht des Systems nicht ändern, aber die Implementierungsschicht des Systems darf erweitert werden . Mit anderen Worten: Definieren Sie eine einmalige Abstraktionsentwurfsebene, die es ermöglicht, so viel Verhalten wie möglich auf der Implementierungsebene zu implementieren.
Der Schlüssel zur Lösung von Problemen liegt in der Abstraktion, der ersten Kernessenz des objektorientierten Designs.
Etwas zu abstrahieren bedeutet im Wesentlichen, seine Essenz zusammenzufassen. Abstraktion ermöglicht es uns, die wichtigsten Dinge zu erfassen und auf einer höheren Ebene zu denken. Dadurch verringert sich die Komplexität des Denkens und wir müssen nicht mehr über so viele Dinge gleichzeitig nachdenken. Mit anderen Worten: Wir erfassen das Wesentliche der Dinge und können keine Details erkennen.
Bei der objektorientierten Programmierung werden durch abstrakte Klassen und Schnittstellen die Eigenschaften konkreter Klassen als Abstraktionsschicht festgelegt, die relativ stabil ist und nicht geändert werden muss, wodurch die Anforderung „geschlossen gegenüber Änderungen“ erfüllt wird. ; während konkrete Klassen, die von abstrakten Klassen abgeleitet sind, das Verhalten des Systems so ändern können, dass es die „Offenheit für Erweiterung“ erfüllt.
Beim Erweitern der Entität besteht keine Notwendigkeit, den Quellcode oder Binärcode der Software zu ändern. Der Schlüssel liegt in der Abstraktion.

2. LSP
Vollständiger Name: „Liskov-Substitutionsprinzip“ Liskov-Substitutionsprinzip
Hinweis: Untertyp muss Fähigkeit zu Ersetzen Sie ihre Basistypen. Wenn eine Softwareentität eine Basisklasse verwendet, ändert sich das Verhalten des Programms nicht, wenn die Basisklasse durch eine Unterklasse ersetzt wird, die die Basisklasse erbt. Softwareentitäten sind sich des Unterschieds zwischen Basisklassenobjekten und Unterklassenobjekten nicht bewusst.
Vorteile: Es ist einfach, den Austausch von Unterklassen unter derselben übergeordneten Klasse zu realisieren, ohne dass der Client sich dessen bewusst ist.

3. DIP
Vollständiger Name: „Abhängigkeitsinversionsprinzip“ Abhängigkeitsinversionsprinzip
Erklärung: Verlassen Sie sich auf Abstraktion, nicht auf Konkretheit. Kunden verlassen sich auf abstrakte Kopplung.
Abstraktion sollte nicht von Details abhängen; Details sollten von der Abstraktion abhängen;
Die Programmierung sollte für Schnittstellen erfolgen, nicht für die Implementierung.
Vorteile: Durch die Verwendung der durch die traditionelle prozedurale Programmierung erzeugten Abhängigkeiten hängt die Strategie von den Details ab, was schlecht ist, da die Strategie durch Änderungen in den Details beeinflusst wird. Das Abhängigkeitsinversionsprinzip macht Details und Strategien von der Abstraktion abhängig, und die Stabilität der Abstraktion bestimmt die Stabilität des Systems.
Wie erreicht man eine Abhängigkeitsumkehr?
Abstrakte Kopplung ist der Schlüssel zum Abhängigkeitsinversionsprinzip. Abstrakte Kopplungsbeziehungen beinhalten immer konkrete Klassen, die von abstrakten Klassen erben, und es muss sichergestellt werden, dass jeder Verweis auf die Basisklasse auf ihre Unterklasse geändert werden kann. Daher ist das Liskov-Substitutionsprinzip die Grundlage des Abhängigkeitsinversionsprinzips.
Obwohl die Kopplung auf der abstrakten Ebene flexibel ist, bringt sie auch zusätzliche Komplexität mit sich. Wenn die Möglichkeit einer Änderung einer bestimmten Klasse sehr gering ist, sind die Vorteile der abstrakten Kopplung sehr begrenzt Besser ist es, eine Betonkupplung zu verwenden.
Hierarchie: Alle gut strukturierten objektorientierten Architekturen verfügen über klare Schichtdefinitionen, und jede Schicht stellt über eine gut definierte, kontrollierte Schnittstelle eine Reihe zusammenhängender Dienste nach außen bereit.
Abhängig von der Abstraktion: Es wird empfohlen, sich nicht auf konkrete Klassen zu verlassen, d. h. alle Abhängigkeiten im Programm sollten an abstrakten Klassen oder Schnittstellen enden. Versuchen Sie Folgendes:
1. Keine Variable sollte einen Zeiger oder Verweis auf eine bestimmte Klasse enthalten.
2. Keine Klasse sollte von einer konkreten Klasse abgeleitet werden.
3. Keine Methode sollte die implementierte Methode in einer ihrer Basisklassen überschreiben.

4. ISP
Vollständiger Name: „Interface Segregation Principle“ Schnittstellenisolationsprinzip
Erklärung: Es ist immer besser, mehrere dedizierte Funktionsschnittstellen zu verwenden, als eine Gesamtschnittstelle zu verwenden . Aus Sicht einer Client-Klasse: Die Abhängigkeit einer Klasse von einer anderen Klasse sollte auf der Mindestschnittstelle basieren. Eine übermäßig aufgeblähte Schnittstelle stellt eine Verschmutzung der Schnittstelle dar und sollte Clients nicht dazu zwingen, sich auf Methoden zu verlassen, die sie nicht verwenden.
Vorteile: Wenn eine Softwaresystemfunktion erweitert wird, wird der Änderungsdruck nicht auf andere Objekte übertragen.
So implementieren Sie das Schnittstellenisolationsprinzip
Benutzer sollten nicht gezwungen werden, sich auf Methoden zu verlassen, die sie nicht verwenden.
1. Verwenden Sie die Delegation, um Schnittstellen zu trennen.
2. Verwenden Sie Mehrfachvererbung, um Schnittstellen zu trennen.

5. CARP oder CRP
Vollständiger Name: „Composite/Aggregate-Wiederverwendungsprinzip“ Synthese-/Aggregation-Wiederverwendungsprinzip oder „ Prinzip der zusammengesetzten Wiederverwendung“Prinzip der zusammengesetzten Wiederverwendung
Hinweis: Wenn einige Funktionen des neuen Objekts in anderen bereits erstellten Objekten implementiert wurden, versuchen Sie, die Funktionalität anderer Objekte so bereitzustellen, dass es funktioniert wird Teil des neuen Objekts, anstatt es selbst neu zu erstellen. Neue Objekte erreichen die Wiederverwendung bestehender Funktionalität, indem sie an diese Objekte delegieren.
Kurz gesagt: Versuchen Sie, Zusammensetzung/Aggregation zu verwenden und keine Vererbung zu verwenden.
Vorteile:
1) Die einzige Möglichkeit für ein neues Objekt, auf Komponentenobjekte zuzugreifen, ist über die Schnittstelle des Komponentenobjekts.
2) Diese Art der Wiederverwendung ist eine Black-Box-Wiederverwendung, da die internen Details der Komponentenobjekte für das neue Objekt unsichtbar sind.
3) Diese Art der Wiederverwendung unterstützt die Verpackung.
4) Diese Art der Wiederverwendung erfordert weniger Abhängigkeiten.
5) Jede neue Klasse kann sich auf eine Aufgabe konzentrieren.
6) Diese Art der Wiederverwendung kann dynamisch zur Laufzeit durchgeführt werden, und neue Objekte können dynamisch auf Objekte desselben Typs wie die Komponentenobjekte verweisen.
7) Als Wiederverwendungsmethode kann es auf fast jede Umgebung angewendet werden.
Nachteile:
Das heißt, es gibt mehr Objekte im System, die verwaltet werden müssen.

6. LOD oder LKP
Vollständiger Name: „Gesetz von Demeter“ Demeter-Prinzip oder „Least-Knowledge-Prinzip“ Least-Knowledge-Prinzip
Erklärung: Objekte sollten auf möglichst wenige Arten miteinander in Beziehung stehen, um untrennbare Beziehungen zu vermeiden.
So implementieren Sie das Demeter-Gesetz
Der Hauptzweck des Demeter-Gesetzes besteht darin, die Informationsüberflutung zu kontrollieren. Bei der Anwendung auf das Systemdesign sollten Sie auf die folgenden Punkte achten:
1) In Bezug auf die Klasse Division, Klassen sollten mit schwacher Kopplung erstellt werden. Je schwächer die Kopplung zwischen Klassen ist, desto einfacher ist es, sie wiederzuverwenden.
2) Im Hinblick auf das Design der Klassenstruktur sollte jede Klasse die Zugriffsrechte der Mitglieder minimieren. Eine Klasse sollte ihre Eigenschaften nicht öffentlich machen, sondern Methoden zum Abrufen und Zuweisen von Werten bereitstellen, um der Außenwelt den indirekten Zugriff auf ihre Eigenschaften zu ermöglichen.
3) Beim Klassendesign sollte eine Klasse wann immer möglich so gestaltet werden, dass sie eine unveränderliche Klasse ist.
4) In Bezug auf Verweise auf andere Objekte sollten die Verweise einer Klasse auf andere Objekte minimiert werden.


Es gibt auch ein Single-Responsibility-Prinzip:

SRP – Single-Responsibility-Prinzip): Was eine Klasse betrifft, sollte sie sich nur konzentrieren on Eine Sache tun und nur einen Grund dafür haben, dass sie sich ändert . Die sogenannten Verantwortlichkeiten können als Funktionen verstanden werden, was bedeutet, dass die entworfene Funktion nur eine Funktion haben sollte, nicht zwei oder mehr. Dies kann auch als Grund für die Referenzänderung verstanden werden. Wenn Sie feststellen, dass es zwei Änderungen gibt, die eine Änderung dieser Klasse erforderlich machen, sollten Sie erwägen, diese Klasse zurückzuziehen. Da Verantwortung eine Achse des Wandels ist, spiegelt sich bei einer Änderung der Anforderungen die Änderung in den Verantwortlichkeiten der Klasse wider. Zu beachtende Punkte bei der Verwendung von SRP: 1. Eine vernünftige Klasse sollte nur einen Grund für ihre Änderung haben, d. h. eine einzige Verantwortung. 2. Es ist unklug, SRP oder andere Prinzipien anzuwenden, ohne Anzeichen einer Änderung 3. Wenn sich die Anforderungen tatsächlich ändern, sollten Prinzipien wie SRP angewendet werden, um den Code umzugestalten Sie können die Trennung von Verantwortlichkeiten nicht erzwingen, da der Geruch von Starrheit und Fragilität sehr stark wird. Dann sollten Sie den Fassaden- oder Proxy-Modus verwenden, um den Code umzugestalten. Vorteile: Eliminieren Sie die Kopplung und reduzieren Sie die Codestarrheit, die durch Änderungen in den Anforderungen verursacht wird.



Sie müssen sich nicht strikt an diese Grundsätze halten und es gibt keine religiösen Strafen für deren Verstöße. Aber Sie sollten sich diese Grundsätze als Alarmglocken vorstellen. Wenn einer von ihnen verletzt wird, ertönt die Alarmglocke.

-----Arthur J.Riel
(1) Alle Daten sollten in der Klasse verborgen sein, in der sie sich befinden. (2) Benutzer einer Klasse müssen sich auf die gemeinsame Schnittstelle der Klasse verlassen, eine Klasse kann sich jedoch nicht auf ihre Benutzer verlassen. p15 (3) Minimieren Sie die Nachrichten im Klassenprotokoll.
(4) Implementieren Sie die grundlegendste öffentliche Schnittstelle, die alle Klassen verstehen [z. B. Kopiervorgänge (tiefe Kopie und flache Kopie), Gleichheitsbeurteilung, korrekten Ausgabeinhalt, Analyse anhand der ASCII-Beschreibung usw.]. p16
(5) Fügen Sie keine Implementierungsdetails (z. B. private Funktionen, die gemeinsam genutzten Code platzieren) in die öffentliche Schnittstelle der Klasse ein.
Wenn zwei Methoden einer Klasse einen gemeinsamen Code haben, können Sie eine private Funktion erstellen, die diese gemeinsamen Codes verhindert.
(6) Stören Sie die öffentliche Schnittstelle einer Klasse nicht mit Dingen, die Benutzer nicht verwenden können oder an denen sie kein Interesse haben. p17
(7) Es sollte keine Kopplung zwischen Klassen oder nur abgeleitete Kopplungsbeziehungen geben. Das heißt, eine Klasse hat entweder nichts mit einer anderen Klasse zu tun oder sie verwendet nur Operationen in der öffentlichen Schnittstelle einer anderen Klasse. p18
(8) Klassen sollten nur eine Schlüsselabstraktion darstellen.
Alle Klassen im Paket sollten gemeinsam geschlossen werden, um Änderungen am gleichen Eigenschaftstyp zu verhindern. Wenn sich eine Änderung auf ein Paket auswirkt, wirkt sie sich auf alle Klassen im Paket aus, hat jedoch keine Auswirkungen auf andere Pakete.
(9) Zentralisieren Sie verwandte Daten und Verhaltensweisen.
Designer sollten auf Objekte achten, die durch Operationen wie get Daten von anderen Objekten abrufen. Diese Art von Verhalten impliziert, dass dieses empirische Prinzip verletzt wird.
(10) Ordnen Sie irrelevante Informationen einer anderen Klasse zu (das heißt, das Verhalten, nicht miteinander zu kommunizieren). p19
Gehen Sie zu stabilen Abhängigkeiten über
(11) Stellen Sie sicher, dass das abstrakte Konzept, das Sie modellieren, eine Klasse ist und nicht nur die Rolle, die ein Objekt spielt. p23
(12) Verteilen Sie Systemfunktionen so gleichmäßig wie möglich in horizontaler Richtung, das heißt: Gemäß dem Entwurf sollten Klassen der obersten Ebene die Arbeit gleichmäßig teilen.
(13) Erstellen Sie keine allmächtigen Klassen/Objekte in Ihrem System. Seien Sie besonders vorsichtig bei Klassen, deren Namen Driver, Manager, System und Susystem umfassen.
Planen Sie eine Schnittstelle, anstatt sie zu implementieren.
(14) Seien Sie vorsichtig bei Klassen, die eine große Anzahl von Zugriffsmethoden in der öffentlichen Schnittstelle definieren. Aufgrund der Vielzahl an Zugriffsmöglichkeiten werden relevante Daten und Verhaltensweisen nicht zentral gespeichert.
(15) Seien Sie vorsichtig bei Klassen, die zu viele Verhaltensweisen enthalten, die nicht miteinander kommunizieren.
Eine weitere Manifestation dieses Problems ist das Erstellen vieler Get- und Set-Funktionen in der öffentlichen Schnittstelle der Klasse in Ihrer Anwendung.
(16) In einer Anwendung, die aus einem objektorientierten Modell besteht, das mit der Benutzeroberfläche interagiert, sollte das Modell nicht von der Schnittstelle abhängen, sondern die Schnittstelle sollte vom Modell abhängen.
(17) Modellieren Sie so weit wie möglich nach der realen Welt (wir verstoßen häufig gegen dieses Prinzip, um das Prinzip der Systemfunktionsverteilung einzuhalten, das Allzweckklassenprinzip zu vermeiden und verwandte Daten und Verhaltensweisen zentral zu platzieren) .
(18) Entfernen Sie unnötige Klassen aus Ihrem Design.
Im Allgemeinen werden wir diese Klasse auf eine Eigenschaft herabstufen.
(19) Klassen außerhalb des Systems entfernen.
Das Merkmal von Klassen außerhalb des Systems ist, dass sie abstrakt gesehen nur Nachrichten an die Systemdomäne senden, aber keine Nachrichten von anderen Klassen in der Systemdomäne akzeptieren.
(20)Verwandeln Sie Operationen nicht in Klassen. Befragen Sie jede Klasse, deren Name ein Verb ist oder von einem Verb abgeleitet ist, insbesondere eine Klasse mit nur einer sinnvollen Aktion. Überlegen Sie, ob dieses sinnvolle Verhalten in eine Klasse verschoben werden sollte, die bereits existiert oder noch nicht entdeckt wurde.
(21) Bei der Erstellung von Analysemodellen für Anwendungen führen wir häufig Proxy-Klassen ein. Während der Entwurfsphase stellen wir häufig fest, dass viele Agenten nutzlos sind und entfernt werden sollten.
(22) Versuchen Sie, die Anzahl der Mitarbeiter einer Klasse zu reduzieren.
Die Anzahl der von einer Klasse verwendeten anderen Klassen sollte so gering wie möglich sein.
(23) Minimieren Sie die Anzahl der Nachrichten, die zwischen Klassen und Mitarbeitern ausgetauscht werden.
(24) Minimieren Sie den Umfang der Zusammenarbeit zwischen Klassen und Mitarbeitern, das heißt: Reduzieren Sie die Anzahl der unterschiedlichen Nachrichten, die zwischen Klassen und Mitarbeitern ausgetauscht werden.
(25) Minimieren Sie das Fan-Out der Klasse, das heißt: Reduzieren Sie das Produkt aus der Anzahl der von der Klasse definierten Nachrichten und der Anzahl der gesendeten Nachrichten
(26) Wenn die Klasse Objekte einer anderen Klasse enthält , dann sollte die enthaltende Klasse das enthaltene Objekt sein, das die Nachricht sendet. Das heißt: Eine Inklusionsrelation impliziert immer eine Nutzungsrelation.
(27) Die meisten in einer Klasse definierten Methoden sollten die meiste Zeit die meisten Datenelemente verwenden.


(28) Die Anzahl der in einer Klasse enthaltenen Objekte sollte die Kapazität des Kurzzeitgedächtnisses des Entwicklers nicht überschreiten. Diese Zahl ist oft 6.
Wenn eine Klasse mehr als 6 Datenelemente enthält, können Sie die logisch verbundenen Datenelemente in eine Gruppe aufteilen und dann eine neue enthaltende Klasse verwenden, um diese Gruppe von Elementen aufzunehmen.
(29) Lassen Sie Systemfunktionen vertikal in einem engen und tiefen Vererbungssystem verteilen.
(30) Bei der Implementierung semantischer Einschränkungen ist es am besten, diese basierend auf Klassendefinitionen zu implementieren. Dies führt häufig zu einem Klassenüberlauf. In diesem Fall sollten die Einschränkungen im Verhalten der Klasse implementiert werden, normalerweise, aber nicht unbedingt, im Konstruktor.
(31) Wenn Sie semantische Einschränkungen im Konstruktor einer Klasse implementieren, platzieren Sie den Einschränkungstest auf der tiefsten Einschlussebene, die das Konstruktorfeld zulässt.
(32) Wenn sich die semantischen Informationen, auf denen Einschränkungen beruhen, häufig ändern, ist es am besten, sie in einem zentralen Objekt eines Drittanbieters zu platzieren.
(33) Wenn sich die semantischen Informationen, auf denen Einschränkungen beruhen, selten ändern, dann Es wird am besten auf die verschiedenen Klassen verteilt, die an den Einschränkungen beteiligt sind.
(34)Eine Klasse muss wissen, was sie enthält, aber sie kann nicht wissen, wer es enthält.
(35) Objekte, die einen gemeinsamen Literalbereich haben (d. h. in derselben Klasse enthalten sind), sollten keine Nutzungsbeziehung zueinander haben.
(36) Vererbung sollte nur zur Modellierung von Spezialisierungshierarchien verwendet werden.
(37) Abgeleitete Klassen müssen die Basisklasse kennen, und Basisklassen sollten keine Informationen über ihre abgeleiteten Klassen kennen.
(38) Alle Daten in der Basisklasse sollten privat sein, keine geschützten Daten verwenden.

Klassendesigner sollten niemals Dinge in öffentliche Schnittstellen einfügen, die von Benutzern der Klasse nicht benötigt werden.
(39) Theoretisch sollte die Vererbungshierarchie tiefer sein, je tiefer desto besser.
(40)In der Praxis sollte die Tiefe der Vererbungshierarchie die Kurzzeitgedächtniskapazität einer durchschnittlichen Person nicht überschreiten. Ein weithin akzeptierter Tiefenwert ist 6
(41) Alle abstrakten Klassen sollten Basisklassen sein
(42) Alle Basisklassen sollten abstrakte Klassen sein
(43) Platzieren Sie Gemeinsamkeiten in Daten, Verhalten und/oder Schnittstellen so weit oben in der Vererbungshierarchie wie möglich.
(44) Wenn zwei oder mehr Klassen gemeinsame Daten teilen (aber kein gemeinsames Verhalten), sollten die gemeinsamen Daten in einer Klasse platziert werden, und jede Klasse, die diese Daten teilt, enthält diese Klasse.
(45) Wenn zwei oder mehr Klassen gemeinsame Daten und Verhaltensweisen (d. h. Methoden) haben, sollte jede dieser Klassen von einer gemeinsamen Basisklasse erben, die diese Daten und Methoden darstellt. (46) Wenn zwei oder mehr Klassen eine gemeinsame Schnittstelle haben (die sich auf Nachrichten bezieht, nicht auf Methoden), sollten sie nur dann von einer gemeinsamen Basisklasse erben, wenn sie polymorph verwendet werden müssen. (47) Eine Einzelfallanalyse der Darstellung von Objekttypen ist grundsätzlich falsch. In den meisten Fällen sollten Designer Polymorphismus verwenden.
(48) Eine Einzelfallanalyse der Anzeige von Attributwerten ist oft falsch. Klassen sollten in eine Vererbungshierarchie entkoppelt werden, wobei jeder Attributwert in eine abgeleitete Klasse umgewandelt wird.


(49) Modellieren Sie die dynamische Semantik einer Klasse nicht durch Vererbungsbeziehungen. Der Versuch, dynamische Semantik mit statischen semantischen Beziehungen zu modellieren, führt zur Laufzeit zu einem Typwechsel.
(50)Verwandeln Sie Klassenobjekte nicht in abgeleitete Klassen. Seien Sie vorsichtig bei abgeleiteten Klassen, die nur eine Instanz haben.
(51) Wenn Sie der Meinung sind, dass Sie zur Laufzeit eine neue Klasse erstellen müssen, treten Sie einen Schritt zurück und stellen Sie fest, dass Sie Objekte erstellen. Verallgemeinern Sie nun diese Objekte in einer Klasse.
(52) Es sollte illegal sein, eine leere Methode (d. h. eine Methode, die nichts tut) in einer abgeleiteten Klasse zu verwenden, um eine Methode in der Basisklasse zu überschreiben.
(53) Verwechseln Sie die optionale Einbeziehung nicht mit der Notwendigkeit einer Vererbung. Die Modellierung optionaler Inklusion als Vererbung führt zu einer Verbreitung von Klassen.
(54) Versuchen Sie beim Erstellen von Vererbungshierarchien, wiederverwendbare Frameworks anstelle wiederverwendbarer Komponenten zu erstellen.
(55) Wenn Sie in Ihrem Design Mehrfachvererbung verwenden, gehen Sie davon aus, dass Sie einen Fehler gemacht haben. Wenn Sie keinen Fehler gemacht haben, müssen Sie versuchen, ihn zu beweisen.
(56) Solange Vererbung im objektorientierten Design verwendet wird, stellen Sie sich zwei Fragen: (1) Ist die abgeleitete Klasse ein besonderer Typ der Sache, die sie erbt? (2) Ist die Basisklasse Teil der abgeleiteten Klasse?
(57) Wenn Sie in einem objektorientierten Design mehrere Vererbungsbeziehungen finden, stellen Sie sicher, dass keine Basisklasse tatsächlich eine abgeleitete Klasse einer anderen Basisklasse ist.
(58) Wenn Sie beim objektorientierten Design zwischen Inklusion und Assoziation wählen müssen, wählen Sie bitte Inklusion.
(59) Verwenden Sie keine globalen Daten oder globalen Funktionen für die Buchhaltung von Klassenobjekten. Es sollten Klassenvariablen oder Klassenmethoden verwendet werden.
(60) Objektorientierte Designer sollten nicht zulassen, dass physikalische Designprinzipien ihre logischen Designs untergraben. Bei Entscheidungen über das logische Design verwenden wir jedoch häufig physikalische Designkriterien.
(61) Umgehen Sie nicht die öffentliche Schnittstelle, um den Status des Objekts zu ändern.

Das obige ist der detaillierte Inhalt vonEinführung in objektorientierte Prinzipien in PHP. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!