OOP – Objektorientierte Programmierung. OOP-Denken bezieht sich auf die Idee der Objektorientierung. OOP-Design bedeutet nicht, den gesamten Code in Klassen zu kapseln. Denn wenn das so ist, dann bezieht sich das nur auf die objektorientierte Programmierung.
OOP – objektorientierte Programmierung ist nur eine Übung. OOP-Denken ist von grundlegender Bedeutung. Entscheidend ist nicht die Herangehensweise, sondern das tatsächlich zu erreichende Ziel.
Die JAVA-Sprache kann immer die meisten objektorientierten Ziele erreichen. Der Grund ist ganz einfach. Das liegt an den Einschränkungen der Sprache selbst.
Alles in JAVA muss in einer Klasse sein. Eigenständige Funktionen außerhalb der Klasse sind nicht zulässig. Designmuster existieren erst seit dem Aufkommen von JAVA. Unter diesem Gesichtspunkt hat JAVA das Denken in der Softwarewelt verändert.
Das Ziel von OOP ist es, dafür zu sorgen, dass der Code den SOLID-Prinzipien entspricht. Diese Prinzipien werden am Anfang jedes Buches über Designmuster vorgestellt.
Aber das ist ein theoretisches Ziel. Das eigentliche Ziel besteht darin, zu beantworten, warum wir tun, was wir tun. Weil wir die Zukunft immer nicht kennen. Wir wissen nicht, wie sich die Nachfrage verändern wird. Möglicherweise können wir heute nur für eine begrenzte Zeit eine vereinfachte Version bereitstellen. Aber es wird auf jeden Fall in Zukunft erweitert. Was wir heute getan haben, mag heute alles abgedeckt haben, aber eines Tages werden wir feststellen, dass es noch eine weitere Komponente gibt, die nicht berücksichtigt wurde.
Wenn es keine Objektorientierung gibt, haben wir es mit der einfachsten Schaltergehäusestruktur vervollständigt. Aus diesem Grund mussten wir unseren Kerncode überarbeiten. Wenn unser Code jedoch dem SOLID-Prinzip entspricht, müssen wir lediglich eine neue KLASSE zum vorhandenen Code hinzufügen.
Es ist nicht schwer zu finden: Die Plug-in-Idee stammt von OOP. Wenn wir uns zu diesem Zeitpunkt also OOP ansehen, geht es nicht nur darum, verstreuten Code in Klassen zu kapseln.
Wir müssen dem SOLOD-Prinzip folgen und klären, was abstrakt und was konkret ist. Wir stellen nur begrenzten problemspezifischen Code bereit, aber alle basieren auf der Gesamtabstraktion. Wenn es neue spezifische Probleme desselben Typs gibt, müssen wir nur Klassen hinzufügen. Dies ist der Kern der Idee von Design Patterns.
OOP-Design ist weit davon entfernt. Die Lesbarkeit und Wartbarkeit des Codes hängt auch vom Verzeichnis und der Dokumentation ab. Oberflächlich betrachtet ist dies kein wichtiges Detail. Aber die Realität ist extrem wichtig. Insbesondere der Entwurf von Kernmodulen für ein bestimmtes Problem oder der Entwurf eines PHP-Entwicklungsframeworks. Die Lesbarkeit eines Verzeichnisses oder ob es OOP-konform ist, bestimmt maßgeblich, wie schnell die Leute es verstehen und wie bereit sie sind, es zu akzeptieren. Beispielsweise ist die Verzeichnisstruktur von SYSMFONY nicht sehr gut. Obwohl es sich um eine alte Marke handelt, besetzte sie in der Anfangsphase einen großen Markt. Der Markt ist jedoch immer noch durch einige neue Rahmenbedingungen gespalten. Rückblickend waren diese Codes nicht sehr gut gestaltet, wie zum Beispiel KOHANA, aber CI war recht einfach zu akzeptieren und hing auch mit seiner Verzeichnisstruktur zusammen. Dies ist auch der Grund, warum einige inländische Frameworks von Benutzern akzeptiert werden können. Das liegt nicht nur daran, dass es sich um die chinesische Version handelt.
Es ist ersichtlich, dass die Idee des OOP-Designs nicht nur in Bezug auf Code, sondern in allen Aspekten von Architektur und Design besteht.
Die überwiegende Mehrheit der Probleme mit dem PHP-Framework sind darauf zurückzuführen, dass Open-Source-Systeme nicht über ausreichend erfahrene Architekten verfügen, die wirklich sehr große Projekte erlebt haben. Das ist durchaus entschuldbar. Wenn ein Unternehmen jedoch Open Source nutzt, wird das System nach vielen Betriebsjahren größer und komplexer, und es wird eine Tragödie sein, wenn es keine klare Architektur haben kann, die einfach zu verwenden und zu warten ist.
Einige Leute sagen, dass diese Unternehmen dies nutzen können, um Geld für Kunden zu verdienen, die eine Sekundärentwicklung benötigen. Tatsächlich ist es immer begrenzt, so viel Geld zu verdienen. Denn eine gute Kernarchitektur wird eine echte Software-Industrialisierung bewirken. Und es wird erhebliche Kosteneinsparungen geben.
Tatsächlich ist das Entwicklungsframework eigentlich recht einfach. Es ist so einfach, dass es in ein oder zwei Sätzen zusammengefasst werden kann: Stellen Sie zunächst verschiedene Klassenbibliotheken bereit, die Benutzer aufrufen können, sodass Benutzer weniger Code schreiben müssen. Die zweite besteht darin, Benutzern das einfache Hinzufügen der benötigten Plug-Ins zu ermöglichen und die Benutzerentwicklung zu reduzieren. Dies ist eigentlich ein verwandtes System, das sich gegenseitig anruft. Im MVC-System, dem reinen OOP-Framework, ist letzteres das Framework, das den Code des Benutzers aufruft. In diesem Aspekt ist die Benutzeroberflächenkomponente die wichtigste. PHP verfügt über eine große Anzahl von Frameworks in dieser Kategorie. Aber sie sind alle sehr elementar. Keiner kann mit FCS oder TYPESTRY in JAVA verglichen werden. Einige Anfänger können sogar eine Tag-Engine veröffentlichen, die weniger als 200 KB groß ist. Sie können es sich vorstellen, ohne einen Blick auf den Code zu werfen. Es wird niemals ein Entwurfsmuster geben, geschweige denn SOLIDE Prinzipien. Dann werden Ausbau und Wartung erhebliche Probleme bereiten.
Also haben wir darüber nachgedacht, wie viele Internetunternehmen ihre Websites mit PHP betreiben. Oberflächlich betrachtet scheint PHP die Kosten zu senken, aber inwieweit kann es gesenkt werden? Der Schlüssel liegt immer noch vom OOP-Code zur OOP-Architektur. Die Ebene der OOP-Architektur bestimmt die Effizienz und die Kosten der Entwicklung durch die technische Abteilung.
