Sinnhaftigkeit der Objektorientierung in PHP

[unset]

Es ist allerdings wesentlich sinnvoller, sich ein gutes Buch zur Hand zu nehmen (konkret das hier) und sich anzuschauen, wie bewährte Systeme diese Pattern implementiert haben, als ohne Sinn und Verstand drauf los zu schreiben –*stets mit der Gefahr, gar nicht kapiert zu haben, was das ganze eigentlich soll.

[ApoY2k]

Gibt einige für PHP, nehmen dir meist viel Arbeit ab und schliessen diverse Fehlerquellen von vorn herein aus, sobald du dich mal eingearbeitet hast. Auch wenn du momentan an etwas kleinerem arbeitest, und du das Gefühl hast mit Kanonen auf Spatzen zu schiessen: der anfängliche Zeitaufwand lohnt sich spätestens mittelfristig.

Das ist mir mittlerweile klar und darauf lass ich mich auch ein. Allerdings bin ich wenig daran interessiert, vorgefertigte Klassen zu benutzen, da ich wirklich verstehen möchte, was genau MVC ausmacht und wie man es umsetzt. Klar, ich könnte mir auch die Klassen anschauen, die in dem Framework drin sind, aber sich daraus etwas beizubringen ist meistens nicht so leicht wie man denkt.

Daher würde ich am liebsten selbst ein kleines Framework dafür aufbauen - es muss ja keinen Anforderungen standhalten, nur fürs Üben ;-)

[AmicaNoctis]

Versuchst du mich zu verwirren?

Nein, gar nicht.

Sehe da gerade keinen Zusammenhang mit Objekten.

Objekte haben Eigenschaften, diese können auch Arrays oder wiederum Objekte beinhalten. Das ganze ist also eine hierarchische Struktur, also ein Baum.

„Ick blicke was was du nik blickst“ – „Boom“
(Bärenbrüder)

[combie]

wenn ich mal in die Verlegenheit komme, Objekte in die DB schreiben zu müssen, mache ich das mit Nested Sets,...

Hmmm...
Versuchst du mich zu verwirren?

Nested Sets dienen dazu Bäume abzubilden, ohne rekursiv arbeiten zu müssen. Sehe da gerade keinen Zusammenhang mit Objekten.

[ThemBones]

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

Kann ich auch wärmstens empfehlen. Und wo wir schon dabei sind: Solltest du dich jetzt für ein OOP-Konzept entscheiden, informier dich gleich über Design und Architekturpatterns.

PHP-spezifisch kenn ich da nur eines (an dem gibts aber auch nix auszusetzen): phpdesignpatterns.de

Könntest noch nen Schritt weiter gehn: sieh dich gleich nach MVC-Frameworks um. Gibt einige für PHP, nehmen dir meist viel Arbeit ab und schliessen diverse Fehlerquellen von vorn herein aus, sobald du dich mal eingearbeitet hast. Auch wenn du momentan an etwas kleinerem arbeitest, und du das Gefühl hast mit Kanonen auf Spatzen zu schiessen: der anfängliche Zeitaufwand lohnt sich spätestens mittelfristig.

[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

[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.
.

[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?

[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.

[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.

[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

[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

[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.

[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 =)

[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