Sinnhaftigkeit der Objektorientierung in PHP

[ApoY2k]

Hallöchen.

Ich habe mal eine vielleicht blöde anmutende Frage an euch. Ich arbeite schon seit längerem mit PHP und habe bisher alle meine Skripte prozedural aufgebaut. Ich kenne Objektorientierung in PHP ebenfalls, aber mehr als just-for-fun-Projekt und nicht wirklich im produktiven Einsatz.

Mir stellt sich nun die Frage, ob es sich überhaupt lohnt, PHP objektorientiert zu machen. Ich meine, ein PHP Skript wird immer bei jedem Aufruf von oben nach unten geparst und interpretiert.

Irgendwie erschließt sich mir da der Sinn von Objekte nicht - Anders als z.B. in Java, wo man das gleiche Objekt öfter benutzen kann über ActionListener etc., ohne dass es bei jeder Useraktion neu erstellt wird.

Vielleicht habe ich noch nicht ganz verstanden, was die OO bei PHP ausmacht, aber nach meinem Verständnis dauert es doch viel länger und ist wesentlich rechenaufwendiger jedes mal alle Klassen und Objekte zu parsen, als wenn man das gleiche Skript einfach runterschreibt wie es halt kommt...

Hoffe mich kann jemand ein bisschen erleuchten

[wahsaga]

Pauschal gilt (m.E.): Der Hauptvorteil von OOP liegt in der Entwicklung, nicht in der Ausführung.

[Kropff]

Pauschal gilt (m.E.): Der Hauptvorteil von OOP liegt in der Entwicklung, nicht in der Ausführung.

Stimmt. Prozeduraler Code neigt dazu, mit der Zeit immer chaotischer zu werden. Ich selber muss mich noch immer durch uralten Code wühlen, der im Laufe der Zeit wild gewachsen ist. OOP erzieht Programmierer zu mehr Sorgfalt (oder sollte es zumindest). Und selbst wenn manche ihre Klassen nur als Scope-Container nutzen, so ist das immer noch übersichtlicher als prozeduraler Code. Auch wenn das dann keine reine OOP mehr ist.

Das einzige was dagegen spricht, ist wenn man OOP um der OOP Willen nutzt. Da hat man dann einen ziemlichen Overhead. Ich kenne das z.B. vom Magento-Shop, wo in unzähligen Objekten die Daten für die DB-Verbindung sieben oder acht Mal auftauchen. Oder Preise inkl. MwSt an fünf verschiedenen Stellen berechnet werden. Da hört es dann auf.

[ApoY2k]

Hm okay, jetzt bleibt die Frage, ab wann man entscheiden kann, ob man OOP nur um dessen Willen benutzt oder es wirklich sinnvoll ist. Ich meine, für Funktionen kann man mehr oder weniger sagen, sobald man etwas in gleicher Weise mehr als zweimal benutzt, lohnt es sich dafür eine Funktion zu machen.

Aber bei Klassen / Objekten ist das wohl nicht zu einfach... Wie kann man sowas entscheiden?

Ich habe ein konkretes Projekt weshalb ich auf das Thema komme, und es gibt da schon mögliche Objekte, die man in Klassen packen könnte, aber ich bin mir nicht sicher, ob es mir das Leben wirklich leichter machen wird...^^

[h3ll]

Hm okay, jetzt bleibt die Frage, ab wann man entscheiden kann, ob man OOP nur um dessen Willen benutzt oder es wirklich sinnvoll ist. Ich meine, für Funktionen kann man mehr oder weniger sagen, sobald man etwas in gleicher Weise mehr als zweimal benutzt, lohnt es sich dafür eine Funktion zu machen.

Aber bei Klassen / Objekten ist das wohl nicht zu einfach... Wie kann man sowas entscheiden?

Ich habe ein konkretes Projekt weshalb ich auf das Thema komme, und es gibt da schon mögliche Objekte, die man in Klassen packen könnte, aber ich bin mir nicht sicher, ob es mir das Leben wirklich leichter machen wird...^^

Sobald du Code wiederverwenden willst, zahlt sich IMHO OOP aus.

[Kropff]

Sobald du Code wiederverwenden willst, zahlt sich IMHO OOP aus.

Jepp. Nimm mal als Beispiel eine Datenbankklasse, die alles Notwendige abarbeitet. Die entwickelst du einmal inkl. aller möglichen Fehlerroutinen und musst dich dann nie wieder darum kümmern. Ich selber weiß kaum noch mehr, wie man die Verbindung zur Datenbank inkl. anschließender Querries prozedural aufbaut. Das macht alles meine DB-Klasse. Und erspart mir jede Menge Arbeit.

Peter

[ApoY2k]

Okay ich denke ich werds mal wagen mit meinem Projekt. Denke gerade im Hinblick auf die Erweiterung ist es sehr praktisch. Wenn ich mal neue Funktionen etc. einbauen möchte...

Zur DB-Klasse: Da benutz ich PDO mittlerweile, ist ne sehr praktische Sache =)

[Helvetier]

Ich stehe vor derselben Frage. Ich möchte für eine kleine Homepage ein einfaches Content Edition System aufbauen (es Content Management zu nennen ist schon fast zu viel gesagt). Ich frage mich, braucht es dazu OOP?

Zum Beispiel mit der DB - Klasse: dazu habe ich Functionen, die in einem Include sind. Diese Include-Datei habe ich jetzt schon mehrmals benutzt. Was bringt es mir, wenn ich diese Functionen nun zusätzlich in eine Class packe?
Die Include-Datei einbinden und fertig ist, scheint mir ebenso einfach wie eine Class zu sein.

[Kropff]

Was bringt es mir, wenn ich diese Functionen nun zusätzlich in eine Class packe? Die Include-Datei einbinden und fertig ist, scheint mir ebenso einfach wie eine Class zu sein.

Hier geht es nur um eine(!) Klasse. Was ist, wenn du mehrere benutzt? Siehe z.B. autoload bzw. spl_autoload_register. Damit kannst du dir die ganzen include-Orgien ersparen.

Peter

[unset]

PHP bietet dir doch an, so zu arbeiten wie du es willst. Ob nun prozedural oder objektorientiert bleibt ganz alleine dir überlassen. In der Praxis sieht es so aus, dass sauberer Code entscheidend für die Wartung ist (und das ist, was in unserem Gewerbe zählt ). Der objekorientierte Ansatz ermöglicht es allerdings wesentlich einfacher wartbaren Code zu erstellen, da eine logische Aufteilung geschaffen wird. Und ja, das kann man auch mit einem Bündel Funktionen erreichen, die man kapselt. Am Ende steht man allerdings in der Regel vor einem Imitat von Objekten –*und verliert damit einen ganzen Batzen Qualität.

Lässt man mal die Terminologie weg, dann hat man, wenn man sich eine Web-Applikation genauer anschaut, einen Haufen Entitäten: Benutzer, Datensätze, Seiten, Menus, Links, etc. All diese Entitäten haben mehr als ein Exemplar –*von denen sich aber jedes mit gleichen Vorraussetzungen auch gleich Verhält. Alleine das schreit förmlich danach, OOP einzusetzen

[combie]

Natürlich könnte man die OOP Tendenz ignorieren, aber man würde damit die letzten 30 Jahre Software Entwicklung in den Wind schlagen.

Tipp:
Halte dich an das Zend/Pear Benennungsschema für Klassen, dann klappts auch gut mit dem Autoloader. Und mache dich über die "OOP Design Pattern" kundig.

[forestsoft_de]

und wenn man sicher gehen möchte das die Anwendung auch so funktioniert wie man es sich vorgestellt hat kann man Unittests für die eigenen erstellten klassen erstellen und somit die Methoden testen.

Noch besser ist natürlich wenn man sich vor dem Entwurf der Klasse Gedanken über deren Aufbau macht, Unittests dafür schreibt und dann nach und nach die Klassen entwickelt und dabei zusehen kann wie die Klasse die vorher geschriebenen Tests besteht.

So behält man noch mehr den Überblick und läuft weniger Gefahr Bugs in die Anwendung zu bauen wenn man noch etwas einbauen oder umstellen muss.

[ApoY2k]

Ich bins schon wieder, mir ist gerade eine Idee gekommen, allerdings wollte ich auch hier erstmal die Kompetenz im Forum fragen ;-)

Wäre es nicht geschickt, Objekte als solches in der Datenbank abzuspeichern? Das würde ja vieles enorm schneller gestalten, z.b. eine Userliste auszulesen - man müsste nur die Objekte aus der Datenbank nehmen, instanzieren und könnte damit direkt arbeiten ohne den Umweg machen zu müssen, die einzelnen Spalten noch in ein Objekt zu schreiben?

[combie]

Die wenigsten Datenbanken kennen native Objekte. Und PHP Objekte schon mal gar nicht.

Also:
Mache dich über ORMs kundig.
Insbesondere das "Doctrine ORM" geht da recht weit und ist sehr einfach zu nutzen.
.

[AmicaNoctis]

Hallo,

wenn ich mal in die Verlegenheit komme, Objekte in die DB schreiben zu müssen, mache ich das mit Nested Sets, Vielleicht hilft dir das ja als Stichwort weiter.

Gruß,

Amica