PHP objektorientiert - warum? Gibt es gute Gründe?

zeroize

zeroize

Erfahrenes Mitglied
Hallo - nach langer Nutzung von Java habe ich mich jetzt wieder PHP zugewandt. Meine alten Projekte waren alle ohne OO programmiert, weil ich damals die Vorzüge nicht kannte. Nun weiß ich ungefähr, wie man OO in PHP programmiert ABER - ich sehe keine Vorteile - eher Nachteile!

Natürlich wird der Programmcode besser strukturiert - aber warum sollte ich erstmal tausende von Objekten erstellen, wenn sie beim beenden des Skriptes wieder gelöscht werden - das macht für mich irgendwie keinen Sinn. In Java erstelle ich meine Objekte, gebe Inhalte von Objekten aus, verändere sie. In PHP muss ich jedes mal die Objekte neu erstellen - warum sollte ich das machen, damit verhunze ich mir doch die Performance eher, oder?

Gibt es hier verfechter der OOP mit PHP? Könnt ihr mich umstimmen?

Danke!
 
zeroize hat gesagt.:
Natürlich wird der Programmcode besser strukturiert
Zum Vergrößern anklicken....
Punkt 1.
zeroize hat gesagt.:
aber warum sollte ich erstmal tausende von Objekten erstellen, wenn sie beim beenden des Skriptes wieder gelöscht werden
Zum Vergrößern anklicken....
Beim Beenden eines Javaprogramms werden die Objekte auch gelöscht.

zeroize hat gesagt.:
In Java erstelle ich meine Objekte, gebe Inhalte von Objekten aus, verändere sie. In PHP muss ich jedes mal die Objekte neu erstellen
Zum Vergrößern anklicken....
Öhm wie bitte? In programmiere auch oo in php und ich gebe, wie in java, Inhalte von Objekten aus und/oder verändere sie. Ich kann da so keinen wirklichen Unterschied erkennen, zumal du Java glaube ich auch nicht mit PHP vergleichen kannst, da in Java nicht objektorientiert zu arbeiten praktisch unmöglich ist.
 
Das Problem ist doch aber, dass das PHP-Programm nicht während der gesamten Nutzung meiner Webanwendung läuft, sondern immer nur wenn Daten abgefragt oder verändert werden. Und dann müssen jedes mal die Objekte erstellt werden. Klar löscht Java die Objekte nach beenden des Programmes - aber das läuft ja auch während der kompletten Nutzung!
 
Ich meine OP glaubt, dass in PHP objektorientierte Programmierung langsam sei, da die PHP Skripte ja nur kurz aufgerufen werden, abgearbeitet werden und dann schon wieder beendet werden, wogegen das Javaprogramm solange läuft, wie der User es benutzt.
Aber das ist ja normal. In einem nicht objekt-orientierten PHP Skript musst du ja trotzdem Werte bei jeder Ausführung von irgenwo herholen, initialisieren und damit arbeiten. Ob es sich dabei um ein paar Objekte handelt oder nicht, macht keinen Unterschied. Du erzeugst ja auch nur die Objekte, die du benötigst.
Dadurch wird der ganze Code häufig überschtlicher, die Funktionen und Daten werden gekappselt und dein Code wird schön wiederverwendbar. Das ganze gilt natürlich nur, wenn du sauber programmiert hast.
Abgesehen davon ist das Erzeugen von ein paar Objekten nicht sonderlich aufwändig.
 
Ich weiß nur eben nicht, ob sich dieser "Zwischenschritt" des Objekterzeugens lohnt. Ich stelle mir vor, ich habe ganze viele Informationen in einer SQL-Datenbank, die ich in Objekte stecke und dann z.B. ausgebe - dann kann ich sie auch gleich ausgeben, je mehr Nachrichten es werden, desto mehr Speicher für Objekte brauche ich - aber der Vorteil das ich Objekte habe, greift dort z.B. garnicht!

Ich weiß natürlich nicht, ob sich das tatsächlich auf die Performance auswirkt - aber mit Speicher um mich zu werfen, muss ja nun auch wieder nicht sein ;-).
 
Vor genau der gleichen Frage stand ich auch vor kurzem. Meine Recherchen im Web zeigten, dass es durchaus viele Diskussionen gibt, ob es sinnvoll ist Webanwendungen objektorientiert zu entwickeln oder nicht (Es geht um Webanwendungen! Nicht um OOP im allgemeinen. Webanwendungen sind von Natur aus eben anders als Desktopanwendungen).
Da ich mit ASP.net entwickele und kein PHP, war meine Frage eher grundsätzlicher Natur. Ich hab praktisch gar nicht die Möglichkeit mich von OOP gänzlich fernzuhalten. Man wird für beide Seiten Argumente finden und auch Beispiele, bei denen jeweils eines der beiden besser funktioniert.

Ein Paradebeispiel für Anti-OOP, welches auch bei anderen Fragen gerne herangezogen wird, ist die Webseite http://www.plentyoffish.com . Es handelt sich dabei um eine Partnerbörse, mit damals (aktuelle Zahlen hab ich jetzt nicht nachgeguckt) 15.000 simultan aggierenden Besuchern. Der Betreiber (eine einzelne Person!) hat die Seite mit ASP.net entwickelt und sie lief zu der Zeit (15.000 Besucher) auf einem einzigen Webserver. In einem Interview sagte er, dass die gesamte Ausgabe via Response.Write() passiert und nicht über die Palette von Steuerelementen, welche das .NET Framework anbietet (DataGridView, Label, Textbox, Button), da diese durch den ganzen OOP Kram einfach zu langsam sind. Im Endeffekt will man doch nur HTML an den Client senden. Dazu noch eine Aussage des Betreibers
In the process of getting rid of ASP.NET repeaters and instead uses the append string thing or response.write. If you are doing over a million page views a day just write out the code to spit it out to the screen.
Zum Vergrößern anklicken....
Wen es interessiert: http://highscalability.com/plentyoffish-architecture

Man merkt schon, das Thema ist nicht mit einem Satz zu beantworten, sondern es lassen sich lange Grundsatzdiskussionen führen.
 
Ich sehe das so: PHP kann auch auf einem Application Server laufen, der Objekte in einem Container vorhällt und sie nach einer gewissen Zeit der Nicht-Verwendung löscht. Sowas gibts meines Wissens nach nicht, weil keine Nachfrage besteht.

Das PHP beim erzeugen von Objekten länger brauchen soll als beim erzeugen von bspw. Arrays (ist in PHP eigentlich auch ein Objekt - nämlich intern eine struktur-basierte Hashtable) halte ich auch für ein Gerücht. Bei Objekten hab ich im Code jetzt nicht nachgesehen, wie sie realisiert werden, dürfte aber ähnlich sein.

Seit PHP 5.3 gibts nen Garbage-Collector, der das Beenden einer Session beschleunigt - da die Objekte eben nachgelagert zerstört werden. Ob der so intelligent ist, Objekte zur weiteren Verwendung in der nächsten Session zur Verfügung zu stellen, habe ich jetzt nicht nachgelesen.

Desweiteren stehen auch in PHP die gleichen Mittel zur Verfügung um Design-Pattern wie Singletons oder Factories zu bauen. Auch das nimmt einen erheblichen Einfluss auf die Performance.

Was mir an PHP missfällt, und auch die objekt-orientierten Ansätze ein bisschen ins Hintertreffen geraten lässt, ist, das es zuwenig Klassen für elementare Dinge wie String, Integer, usw. gibt und viel zu viele prozedurale Funktionen, die in einigen Fällen auch noch das gleiche tut (Beispiel: warum benötigt man 6 oder mehr Methoden zum sortieren eines Arrays, kann man das nicht argumentativ lösen?). Ich hätte gern noch mehr Klassen als das was in SPL angeboten wird.

Fazit: In PHP muss man Klassen für allgemeine Zwecke größtenteils noch selbst bauen um dem OOP-Ansatz gerecht zu werden. Das Parsen von PHP-Code ist natürlich langsamer als wenn der Code in der Library kompiliert zur Verfügung steht. Vielleicht nimmt sich das Core-Team dem Problem irgendwann an oder es gibt jemanden der die Zeit und Lust aufbringt, das als PECL-Extension anzubieten.
 
Um ehrlich zu sein, ich habe keine gute Erfahrung mit PHP, obwohl es die einzige SkriptSprache ist, die ich ein bißchen kann.

Ich finde php ist unstrukturiert, die Namen der Methoden haben kein einheitliches Format, Fehlermeldungen bringen sich nichts.

Was ich gehört habe sind Python und Ruby viel effizienter.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück