Wofür brauch ich OO in php?

[Isabällchen]

Hallo

Ich frage mcih schon seit geraumer Zeit, wie ich in PHP meine Klassen einbauen soll.
Also nicht das Syntaktische "wie" sondern das semantische "wie".
Ich sehe in PHP irgendwie keine Notwendigkeit von Klassen.
Gut, vielleicht für die Verbindung zu einer Datenbank, aber das wars.

Ich komme ursprünglich aus der Java ecke und programmiere dort ganz intuitiv objekt orientiert.
Nun habe ich ein Projekt in php, es soll eine Dating Site werden.
Allerdings sehe ich da nicht genau was meine Objekte sein sollen.
Geschweigedenn irgendwas MVC konformes hinzubekommen.
Das ganze funktioniert auch so, auch wenn es sich zugegebenermassen recht holprig anfühlt und ich absolut nicht damit zufrieden bin.

Vielleicht gehe ich an die ganze Sache falsch heran.
Das Response wird bei mir beispielsweise nicht allein durch php generiert sondern es existiert jeweils ein HTML grundgerüst welches mit php gefüllt wird.

Gibt es irgenwie eine Anleitung wie man in PHP Objekt Orientierte Web Applikationen bastelt? Oder fehlt mir hier nur ein Denkanstoss?

[fanderlf]

Also ich kenne mich in PHP nicht aus, aber warum sollte man da nicht objektorientiert programmieren?
Ich denke eher dass man von Java sehr verwöhnt ist was OOP angeht. Für alle gängigen Geschichten gibt es in Java ein Framework (teils auch mehrere) die einem viel Arbeit abnehmen.
Bei PHP wird da wohl etwas mehr Handarbeit angesagt sein könnte ich mir vorstellen.

Allerdings kann ich auch total daneben liegen

[Christian Marquardt]

Grund dürfte doch eher sein, dass man in Java OO programieren muss und in PHP ein strukturierte Topdownprogrammierung möglich ist

[tinof]

Ganz klar:

Wiederverwendbarkeit von Quellcode.

Zwar fällt der Einstieg deutlich schwerer, aber der 'Aufwand' macht sich bei der ersten Änderung an der Applikation meist schon bezahlt.

Ich habe genauso gedacht (..es geht doch ohne Klassen viel einfacher), musste mich dann aber mit XTCommerce, einem E-Shopsystem auseinandersetzen. Dort sah ich dann, was man alles geniales mit Klassen in PHP machen kann. Eventuell (falls es die Zeit erlaubt) schaust du dir mal so ein 'komerzielles' Projekt (also, einige Teile davon) etwas näher an, ein Beispiel ist immer gut.

Viel Spaß
Tino

[Falk Prüfer]

Hallo,

...Vielleicht gehe ich an die ganze Sache falsch heran.
Das Response wird bei mir beispielsweise nicht allein durch php generiert sondern es existiert jeweils ein HTML grundgerüst welches mit php gefüllt wird.

Gibt es irgenwie eine Anleitung wie man in PHP Objekt Orientierte Web Applikationen bastelt? Oder fehlt mir hier nur ein Denkanstoss?

Wenn man ein HTML-Grundgerüst hat, das mit (wenig) PHP gefüllt wird (um vlt. irgendwo das aktuelle Datum hinzuschreiben, dann brauch ich dafür kein OOP. Wenn du das Ganze aber rumdrehst und eine PHP-Anwendung hast, die HTML-Vorlagen mit "Leben" füllt, dann sieht das schon anders aus. Dann hast du schonmal zur Verwaltung, Befüllen, Ausgabe, etc. dieser Vorlagen (man nennt sie auch Templates) den ersten Ansatz für eine Klasse - eine Template-Klasse. Die wird dann MVC-technisch in die VIEW gepackt.
Je weiter die HTML-Seite zur Anwendung wird, desto mehr Ansätze für Klassen bieten sich. Irgendwo müssen die anzuzeigenden Daten ja her kommen. Dafür brauchts ein MODEL. Eine Grundklasse mit Allgemeinem, Ableitungen für DB oder Filesystem als Datenquelle, etc.
Wenn Daten irgendwo eingegeben werden, müssen die Verarbeitet und darauf reagiert werden, das wird dann ein CONTROLER. Klassen für Datenvalidierung, Kodierung, etc.
Du kannst mit PHP nach MVC völlig abstrakt eine Anwendung programmieren. Lediglich in der VIEW kommst du dann mit HTML in Berührung und wenn es "klassentechnisch" sauber durchgezogen ist, dann kannst du den Inhalt statt in (X)HTML eben auch als PDF oder als XML ausgeben ohne wieder von Vorne anfangen zu müssen.

Gruß Falk

[Novi]

Nun habe ich ein Projekt in php, es soll eine Dating Site werden.

Dort müssen doch garantiert Personen und Dates verwaltet werden. Also könnte man sich schon mal Objekte dafür vorstellen. Wahrscheinlich gibt es noch andere Sachen, die sich bei diesem Projekt gut in Objekten darstellen lassen. Dies macht die Programmierung später einfacher, weil zum Beispiel die alle Daten zu einer Person in einem Objekt sind und z.B nicht in irgendwelchen Arrays, durch die eh kein Mensch mehr durchsteigt. Außerdem sind Funktionen die sich direkt auf diese Daten beziehen in Form von Methoden verfügbar. Dadurch wird alles übersichtlicher, da man genau weiß welche Variablen bzw. welche Methoden zu welchem Objekt gehören. Des Weiteren vereinfachen sich komplexere Probleme auch im Programmcode. Methode können sehr komplex sein und auch noch andere private Methoden des Objektes aufrufen. Wenn man dies mit Funktionen darstellen will bräuchte man mehrere Funktionen, von denen man aber nicht unbedingt alle direkt aufrufen sollte.

Ich hab mal versucht ein kleinen Beispiel-Code zu schreiben:

$UserData1 = getUserData(1);
$UserData2 = getUserData(2);

// Benutzernamen von zwei Benutzern ausgeben ausgeben
echo $UserData1['name'];
echo $UserData2['name'];

// Benutzer Löschen
deleteUser(1);

function getUserData($id) {
    //(...)
    return $Array;
}

function deleteUser($id) {
    deleteDatesFromUser($id);
    deleteUserData($id);
}

function deleteDatesFromUser($id) {
  //(...)
}

function deleteUserData($id) {
  //(...)
} 

Bei der Objekt orientierten Variante, kann man nicht auf die Variable $_Name und auch nicht auf die privaten Funktionen zugreifen. Man kann also weniger falsch machen, auch wenn man nicht genau weiß wie die Klasse funktioniert.

class User
{
    private $_Name;

//(...)

    public function getName() {
        return $this->_Name;
    }

    public function delete() {
        $this->deleteDatesFromUser();
        $this->deleteUserData();
    }
    
    private function deleteDatesFromUser() {
      //(...)
    }
    
    private function deleteUserData() {
      //(...)
    }

}

$User1 = new User(1);
$User2 = new User(2);

// Benutzername ausgeben
echo $User1->getName();
echo $User2->getName();

// Benutzer Löschen
$User1->delete(); 

Ein Weitere Vorteil ist, das du bis zu einem gewissen Grad die Klasse selbst verändern kannst, ohne das du den restlichen Quelltext bearbeiten musst.

[Isabällchen]

Also erstmal vielen Dank für die Antworten.
Mir ist schon klar das OOP besser ist als simples skripte schreiben, aber dann habe ich bisher wohl den Fehler gemacht meine Objekte lediglich in Form einer Tabelle in meiner Datenbank abzulegen, anstatt ein Gerüst in PHP zu bauen und den Inhalt dann jeweils aus der Datenbank zu holen.

Denn sowohl personen als auch Dates sind bei mir nur in der Datenbank existent.
Und entsprechend der eigenen ID, die ich in die Session gepackt hab, bekommt man seine Daten ausgegeben.

Aber es fällt mir nach wie vor etwas schwer mir vorzustellen wie beispielswiese ein User Login über eine Klasse laufen soll und nicht mit der Session, ich mein wozu gibts die Session dann, oder ist die session ein rudiment aus prä OOP zeiten?

[Novi]

Aber es fällt mir nach wie vor etwas schwer mir vorzustellen wie beispielswiese ein User Login über eine Klasse laufen soll und nicht mit der Session, ich mein wozu gibts die Session dann, oder ist die session ein rudiment aus prä OOP zeiten?

Ich muss dir in soweit Recht geben, dass viele PHP Funktionen und Variablen noch nichts mit Objektorientierung zu tun haben. Dennoch kannst du natürlich Sessions in einem Objekt verwenden. Objekte könne keine Session ersetzten.

Hier siehst du einen Auszug aus einer von mir erstellten Klasse

/**
 * Stellt einen Benutzer da.
 */
class User
{

// (...)

    /**
     * Meldet den Benuter mit dem angegebenen Passwort an.
     * @param string $password Das Passwort
     */
    public function login($password) {
        if(!$this->hasRight(Group::RIGHT_CANLOGIN)) {
            throw new AccountBlockedException('deny access to User::login()');
        }
        // check Password
        if(!$this->checkPassword($password)) {
            return false;
        }
        
        $this->_IsLoggedIn = true;
        $_SESSION['isLoggedin'] = true;
        $_SESSION['currentUser'] = serialize($this);
        return true;
    } 

Dass Benutzerobjekt wird auch in der Session gespeichert, damit die Daten nicht jedes mal aus der Datenbank gelesen werden müssen. (Dadurch werden sie natürlich auch erst bei einem erneuten Login aktualisiert!)

[Stefan Priebsch]

Streng genommen braucht man OOP erst mal überhaupt nicht. In der Theorie kann alles, was berechenbar ist, durch ein Programm mit nur einer while-Schleife berechnet werden (http://de.wikipedia.org/wiki/WHILE-Programm). Natürlich macht es keinen Spaß, ein solches Programm zu schreiben geschweige denn zu warten.

Bei OOP geht es hauptsächlich um Lesbarkeit, Wartbarkeit und Erweiterbarkeit. Idealerweise will ich ein vorhandenes Programm erweitern, ohne den bestehenden Quellcode anzufassen. Ein Programm besteht dann irgendwann aus einer Anzahl von (wenn man sauber gearbeitet hat, wiederverwendbaren) Objekten, die zur Laufzeit verdrahtet werden. Anpassungen oder Änderungen nimmt man dann vor, indem man bestimmte Objekte gegen andere austauscht.

Es ist allerdings nicht so ganz leicht, da hinzukommen. Es gibt (leider) viele Beispiele "da draußen" für nicht so guten Code, der sich vielleicht OOP auf die Fahne schreibt und mehr oder weniger viele der OOP-Keywords verwendet, aber eben nicht lesbar, wartbar oder erweiterbar ist. Ein guter Indikator für die Qualität von Objekten ist: welche Umgebung bzw. welche anderen Teile meiner Anwendung brauche ich, wenn ich dieses eine Objekt in einem anderen Zusammenhang wiederverwenden will?

Nach meiner Erfahrung sollte man beim Programmieren Wert auf sauber getrennte Funktionalitäten legen ("Separation of Concerns"). In erster Linie wichtig ist hier, Präsentation, Logik und Datenzugriff zu trennen (leider oft und gerne unsauber oder gar falsch gemacht, auch und besonders wenn MVC auf der Fahne steht). Im nächsten Schritt schaut man sich dann den Code an und überlegt, wie man redundanten oder ähnlichen Code loswerden kann. Wenn man nicht haufenweise globale Variablen verwenden oder ellenlange Parameterlisten haben will, dann ist OOP eigentlich der ganz natürliche nächste Schritt, weil Objekte eben ein (nicht-globales) Gedächtnis bzw. einen Zustand haben. Ich muss also nicht alle Parameter bei jedem Methodenaufruf wieder übergeben, sondern kann das Objekt einmal sauber initialisieren und dann (mit kurzen Parameterlisten) arbeiten.

Zwar wird oft gesagt, Objekte sollten die reale Welt modellieren, für Webanwendungen ist es nach meiner Ansicht aber eher schwierig, von dieser Seite aus zu beginnen. Ich würde den Weg über die konsequente Trennung unterschiedlicher Belange gehen und dann im nächsten Schritt getreu dem Prinzip "andere die Arbeit machen lassen" redundanten Code beseitigen, indem ich neue Methoden oder Objekte erzeuge. Dann komme ich immer mehr in die Richtung, dass verschiedene Objekte zusammenarbeiten, und mein Programm ist nicht mehr prozedural in dem Sinne, dass eine Steuerdatei den zentralen Kontrollfluss vorgibt.

Ein paar Ideen oder Denkanstöße geben vielleicht diese Präsentationen:

http://www.slideshare.net/spriebsch/...p-aber-richtig
http://www.slideshare.net/spriebsch/...-for-zendcon09
http://www.slideshare.net/spriebsch/...esign-patterns

Stefan
http://thePHP.cc

[Isabällchen]

Also erstmal vielen dank für die Antworten, sie haben mich doch um einiges weiter gebracht.
Aber vielleicht auch ein bisschen zu weit.

Stehe momentan vor der Frage ob eine Template Engine wirklich sinnvoll ist, vor allem vor dem Hintergrund was ich in der Zwischenzeit geschrieben habe.
Ich habe mir mal aus spass eine HTML engine Geschrieben.
Jeder HTML Tag ist bei mir nun eine php klasse die ich w3c konform mit attributen, Inhalt oder weiteren HTML Tags versehen kann.
Nun meinte jemand zu mir nimm doch einfach smarty.

Ich habe diese Engine geschrieben damit ich keinen HTML code mehr anfassen muss, sondern alles in PHP, objekt orientiert bearbeiten kann.

Der Vorteil von Smarty ist ja das Präsentation und Programmcode vollständig von einander getrennt sind.
Nun wenn man sich einfach an die Regel hält dies zu trennen, so ist das bei mir ja auch der Fall.
Ich schreibe meine Templates zwar nicht in Smarty Syntax aber im Prinzip ist es doch das gleiche,
mit dem Vorteil das bei mir alles Dynamisch und obekt orientiert ist, sogar meine Templates.

Übersehe ich hier irgendwas, ausser vielleicht sicherheitsaspekten die ich als OOP in PHP anfänger nicht bemerke, was smarty soviel sinnvoller macht?

[Novi]

Stehe momentan vor der Frage ob eine Template Engine wirklich sinnvoll ist, (...)

Vor dieser Frage ob und wenn ja welche Template Engine man einsetzten sollte steht früher oder später so ziemlich jeder Php-Entwickler, der sauber programmieren möchte.

Ich habe mir mal aus spass eine HTML engine Geschrieben.
Jeder HTML Tag ist bei mir nun eine php klasse die ich w3c konform mit attributen, Inhalt oder weiteren HTML Tags versehen kann.
Nun meinte jemand zu mir nimm doch einfach smarty.

Ich habe diese Engine geschrieben damit ich keinen HTML code mehr anfassen muss, sondern alles in PHP, objekt orientiert bearbeiten kann.

Genau das habe ich am Anfang auch probiert. Die Sache hat jedoch einen entscheidenden Nachteil. Anstatt Design von der Programmlogik zu trennen, trennst du nur PHP von HTML.

In meinen Augen sind auch Template-Engines wie Smarty größtenteils überflüssig. (Mir ist bewusst, dass das nicht von allen so gesehen wird.) Man kann nämlich auch wunderbar mit PHP Templates erstellen. Das Ziel ist nämlich gerade nicht HTML und PHP zu trennen, sondern die Programmlogik (z.B. Usereingaben entgegennehmen, Datenbankabfragen, .. ) von der Designlogik zu Trennen: "wie stell ich die Daten dar." (Welches Layout, vielleicht doch als Bild...)

http://php-coding-standard.de/php_template_engine.php

[Falk Prüfer]

Hallo,

...In meinen Augen sind auch Template-Engines wie Smarty größtenteils überflüssig. (Mir ist bewusst, dass das nicht von allen so gesehen wird.) Man kann nämlich auch wunderbar mit PHP Templates erstellen.

Daran scheiden sich wahrhaft die Geister...
Nichtdestotrotz haben reine HTML-Templates einen entscheidenden Vorteil: Sie können mit einem "Webseiten-Design-Programm" auch von einem Nichtprogrammierer erstellt werden. Mal abgesehen davon das ich die Dinger nicht mag (aber ich seh mich eben auch eher als Programmierer) ist das dann entscheidend, wenn in großen Projekten eben nicht nur die Programmlogik vom Layout zu trennen ist, sondern dies auch noch von unterschiedlichen Leuten in unterschiedlichen Abteilungen erledigt wird. Und nicht jeder der sich dort "Webdesigner" nennt hat wirklich Ahnung von HTML, geschweige denn PHP - der hat ein "Webseiten-Design-Programm", das (mehr oder weniger guten) HTML-Code erstellt.

Gruß Falk

[Isabällchen]

Das sehe ich ein, in grossen Firmen, wo man die Arbeit aufteilt und wo leute mit Dreamweaver arbeiten klingt das durchaus sinnvoll eine Template Engine wie Smarty zu benutzen.

Nun arbeite ich momentan alleine und bin so mehr experimentell unterwegs.
Das ich mit meiner Herangehensweise nur PHP von HTML trenne war mir bewusst und das war auch mein Ziel. Ich wollte kein HTML mehr anfassen müssen.
Der Punkt, das ich Programmierlogik und Präsentation trenne ist doch aber hauptsächlich darin manifestiert, wie streng ich mich an diese Trennung halte.
Im Grunde schreibe ich ja auch meine Templates, nur diesmal in PHP.

Ich sehe das als gleichwertig zu einer gängigen Template Engine.
Und bis auf den Umstand das manche Designer nicht programmieren können und sowas wie smarty brauchen sehe ich für mich selbst auch nicht wirklich einen Vorteil (an smarty).
Ich schreibe meine Funktion um beispielsweise den HTML head zu schreiben und kann trotzdem noch Dinge ergänzen, in Smarty schreibe ich eine tpl-datei die dann aber so ist wie sie ist und nur hart umgecodet werden kann.

[A. Fuss]

Hallo Isabällchen,

Smarty ist schon ein guter Schritt in die richtige Richtung. Allerding soll Smarty von der Performance her nicht so gut sein.

Wie in jeder Prog.-Sprache hilft auch bei PHP ein gutes Framework bei der Entwicklung. Die Trennung von HTML-Code (in Templates) und der Programmlogik ist richtig. Es gibt einige Frameworks für PHP, die man verwenden kann. Ich persönlich finde das Prado-Framework (http://pradosoft.com/) gut. Der Ansatz hier ist auch ähnlich zu JSF (Java Server Faces), wie gesagt ähnlich im "weit umfassenden" Sinn gesehen was das Schreiben der Applikation angeht. Beispiele sind auch vorhanden.

Dein Ansatz das Framework selbst zu schreiben ist zwar lobenswert, doch wenn nicht das Framework das eigentliche Ziel der Arbeit ist, sollte man ein bestehendes verwenden, um Zeit zu sparen. Jedenfalls ist das meine Erfahrung.

Schöne Grüße...