OOP in PHP

[vanGoss]

Schönen guten Tag,
ich hab hier irgendwann mal gelesen, dass jemand ein Forum mit OOP selber programmiert hat. Da ich selber dabei bin, wollte ich das auch machen, jedoch viel mir nichts ein, wo das tatsächlich gebraucht wird.

Ich hab es erst versucht, wo einfach eine Liste von Usern ausgegeben wird, aber weil das eh ein while Schleife ist, werden die Daten eigentlich nicht bearbeitet, sondern nur mit __construct gespeichert(OK, hier findet ein wenig Verarbeitung statt) und dann direk danach mit einer eigenen Methode ausgegeben.
Aber eben durch die While Schleife habe ich dann immer ein Objekt, dass immer neu erstellt wird.
Dies kann aber doch auch allein durch eine Funktion wiedergegeben werde.

Und weil nun alle meine anderen Ideen eben auch durch Funktionen zu lösen wären, würde ich gerne wissen, ob entweder Funktionen mehr Performance verschlingen(kann ich mir nicht vorstellen) oder wo man eventuell Klassen oder auch nur Datenstrukturen einsetzten könnte.

Danke
Gruß vanGoss

 

[crash]

Du hast es erfasst. Man kann prozedural oder objektorientiert arbeiten.

OOP bringt nur einige Vorteile, die man mit prozeduraler Programmierung nicht erreichen kann. Dafür ist die Lernkurve hoch und es gibt auch einige Nachteile.

Und wo hast du da keinen Sinn von Klassen gefunden? Mir fällen da direkt Models für die Datenbankzugriff ein und mehrere Service-Layer für Rest, NNTP, RSS usw.

 

[vanGoss]

Das ist ja schön ^^

Nun ja, ich dachte halt, dass die Klassen halt mehr Speicher/Verarbeitungszeit benötigen(Ausschlag für den Thread war, dass ich in einem Essay über Debuggen las, man solle unnötiges Erstellen von Objekten vermeiden).
Und wenn die Klassen dann nur mehr verbrauchen aber nicht mehr bieten fand ich sie schon eher überflüssig.

Aber das galt natürlich nur für selbstgeschriebene, die auf ein spezielles Gebiet weisen, wo die Parameter für eine Funktion auch noch einigermasen überschaubar sind, für vorgefertigte oder allgemeinere sind Klassen durchaus nützlich.

Danke für die Antwort
Gruß
vanGoss

 

[struppi]

Du darfst dir einen Konstruktor nicht vorstellen, wie einen Compiler, der bei jedem Aufruf den Code übersetzt. Letztlich ist ein Objekt nur ein Speicherplatz und die Funktionen werden genau wie in einem funktional geschriebenen Code übersetzt. Der Speichermehrverbrauch ist für Objekte nur minimal. Du hast aber etwas Geschwindigkeitsverlust, weil viel overhead ensteht. Dafür gewinnst du Komfort beim programmieren - bzw. du kannst es.

Wer sich mit funktionalen Programmen wohl fühlt und es schafft auch dort Ordnung rein zu bringen, sollte dabei bleiben.

Den Vorteil von OOP wirst du aber merken, wenn deine Funktionen ständige suffixe bekommen oder wo das Objekt direkt erkennbar ist wie start_html(), open_data() oder getImageSize()

In deinem kurzen Beispiel gäbe es dann Funktionen wie show_user(), show_list(), edit_user(), usw. auch ein Fall für OOP.

Aber du solltest die wenigstens ein paar Sachen durchlesen, was OOP ist, am Anfang ist es immer schwer, weil es manchmal auch sehr abstrakt ist.

 

[vanGoss]

Hmmm durchgelesen habe ich mir schon was, auch bezüglich anderen Programmiersprachen.
Das erste Beispiel war zur Grundlage der Programmierung von irgendwelchen Automaten, war sehr einleuchtend und klar, eig. auch wenig abstrakt.


Dann ist es also im Endeffekt egal, ich denke, dass ich erstmal alles so lasse und spaeter vielleicht wieder Funktionen erstelle.
Vielen Dank fuer die Antworten
Gruss vanGoss

 

[crash]

Unnötige Erzeugung von Objekten ja. Da geht's sicher auch im das Lazy-Loading von Klassen: PHP: Autoloading - Manual

 

[mermshaus]

Nun ja, ich dachte halt, dass die Klassen halt mehr Speicher/Verarbeitungszeit benötigen(Ausschlag für den Thread war, dass ich in einem Essay über Debuggen las, man solle unnötiges Erstellen von Objekten vermeiden).
Und wenn die Klassen dann nur mehr verbrauchen aber nicht mehr bieten fand ich sie schon eher überflüssig.

Abstraktion ist eines der Grundprinzipien von Programmierung und kostet in jeder Form Laufzeit. Das ist völlig normal. Wenn du in einer so weit abstrahierten Sprache wie PHP programmierst, bist du Lichtjahre davon entfernt, effizienten Maschinencode zu produzieren.

Dafür kannst du allerdings auf einfache Art und Weise auf eine große Anzahl getesteter und prinzipiell fehlerfrei arbeitender Grundlagen zurückgreifen. Die enorme Komplexität der Vorgänge, die du auslöst, wenn du im Browser den URL deines Scripts eintippst und Enter drückst, wird durch das hohe Maß an Abstraktion von dir ferngehalten, sodass du dich ganz auf das Erstellen deiner Anwendung konzentrieren kannst.

Das ist ein Prinzip, das bei der niedrigsten Software-/Hardware-Schnittstelle des Betriebssystems beginnt und sich „nach oben“ immer weiter fortsetzt: Ein komplexer Vorgang wird auf möglichst allgemeingültige Weise programmiertechnisch gelöst und hinter einer einfachen Schnittstelle verborgen, die von der nächsthöheren Ebene angesprochen werden kann, ohne dass sich diese mit den tatsächlichen Details befassen muss.

Funktionen in PHP fallen auch in diesen Bereich. Eine Funktion ist ein klar abgegrenzter Programmabschnitt mit einer definierten Eingabe-/Ausgabe-Schnittstelle, die von aufrufendem Code als „funktionierend“ vorausgesetzt und angesprochen werden kann. Du machst die Komplexität im Inneren der Funktion durch einen kleinen Befehlsaufruf verfügbar. Wie die Funktion intern arbeitet, wird dadurch abstrahiert und du kannst dich auf andere Dinge konzentrieren.

Dasselbe leistet auf einer noch einmal übergeordneten Ebene auch die Objektorientierung. Sie fügt dem Konzept „Eingabe-/Ausgabe-Schnittstelle“ beispielsweise das Konzept „Zustand“ hinzu.

Einfache Funktionen haben in dem Sinne keinen eigenen Zustand, sondern verhalten sich im Großen und Ganzen rein deterministisch: Ich erhalte für dieselbe Eingabe üblicherweise zu jedem beliebigen Zeitpunkt dieselbe Ausgabe. Eine Funktion speichert keine Werte zwischen.

Ein Objekt kann Werte zwischenspeichern. Das Verhalten kann von diesen Werten abhängig sein. $person->getName(); liefert nicht immerzu denselben Wert, sondern liefert den Wert, der zum Aufrufzeitpunkt im Objekt als Name zwischengespeichert ist.

Außerdem kann ein Objekt sicherstellen, dass sein Zustand immerzu gültig ist, was beispielsweise einer einfachen Variable oder einem assoziativen Array nicht möglich ist. Eine Variable $name lässt sich problemlos auf "" (leerer String) setzen, ein Objekt kann beim Aufruf von $person->setName(""); feststellen, dass ein leerer String keinen so tollen Namen abgibt, und die Zuweisung durch Auslösen einer Fehlermeldung zurückweisen. Der Zustand des Objekts bleibt damit gültig.

Dadurch ergibt sich wiederum eine Kapselung und eine Abstraktion von Komplexität, da ein Programmierer, der mit einem solchen Objekt arbeitet, sicher sein kann, dass es korrekte Werte liefert, während er das bei einer Variablen oder einem assoziativen Array immerzu prüfen müsste.

 

[mermshaus]

Ich habe den letzten Aspekt kürzlich hier noch etwas ausgeführt (Beitrag #5).

Ohne Objektorientierung würdest du vielleicht irgendwann auf die Idee kommen, sowas zu machen:

<?php

function person_construct($name)
{
    if (!is_string($name) || $name === '') {
        throw new Exception('Name darf nicht leer sein');
    }

    return array('name' => 'Mark van Bommel');
}

function person_isValid(&$person)
{
    if (is_array($person) && isset($person['name'])
            && is_string($person['name']) && $person['name'] !== ''
    ) {
        return true;
    }

    return false;
}

function person_setName(&$person, $name)
{
    if (!person_isValid($person)) {
        throw new Exception('Person ist nicht gültig');
    }

    if ($name === '') {
        throw new Exception('Name darf nicht leer sein');
    }

    $person['name'] = $name;
}

function person_getName(&$person)
{
    if (!person_isValid($person)) {
        throw new Exception('Person ist nicht gültig');
    }

    return $person['name'];
}



$person = person_construct('Mark van Bommel');

echo person_getName($person), "\n";

person_setName($person, 'Lucas Barrios');

echo person_getName($person), "\n";

person_setName($foo, '');

Eine Klasse wäre grundsätzlich im Prinzip erstmal nichts weiter, als eine etwas geschicktere Schreibweise dafür.

 

[sysop]

Das ist ja schön ^^

Nun ja, ich dachte halt, dass die Klassen halt mehr Speicher/Verarbeitungszeit benötigen(Ausschlag für den Thread war, dass ich in einem Essay über Debuggen las, man solle unnötiges Erstellen von Objekten vermeiden).
Und wenn die Klassen dann nur mehr verbrauchen aber nicht mehr bieten fand ich sie schon eher überflüssig.
.....

Auf Grund des "Verbrauches" die Überflüssigkeit von Klassen festzustellen finde ich etwas gewagt
Aber du hast schon ein wenig Recht. Die Tendenzen sind eindeutig in Richtung "alles muss eine Klasse sein" und zum Teil heftig übertrieben. Ich beobachte immer wieder, wie für eine ganz simple Aufgabe Klassen erstellt werden, obwohl es in PHP dafür oftmals einen eigenen fertigen Befehl gibt. Statt sich mir der Befehlsreferenz zu beschäftigen, wird etwas wildes zusammengecoded und als tolle Klasse rausgegeben.

Abstraktion hat nun mal ihren Preis, in wie weit du abstrahieren möchtest oder gar musst, musst du selber entscheiden.
Ich persönlich tendiere auch sehr stark zu Funktionen statt Klassen, der Grund ist aber der, dass ich meine Funktionen speziell für eine Anwendung entwickle und selten bis nie wieder verwenden möchte. Je allgemeiner etwas wird, um so mehr tendiere ich dann auch dazu eine Klasse zu erstellen.

Nicht umsonst werden selten Funktionen zum Download angeboten, da sie meistens sehr speziell auf eine Anwendung ausgelegt sind.

Will man z.B. einen allgemeinen Mailversandt generieren, ist eine Klasse wesentlich angebrachter, weil flexibler, eine Funktion würde das Vorhandensein bestimmter Variablen voraussetzen (z.B. muss es dann $_GET['mailadresse'] lauten und nicht anders.
Zugegeben, sowas kann man auch in eine Funktion bringen, der Aufwand ist dann aber schon so hoch, dass die Erstellung einer Klasse keinen Unterschied mehr macht.

ps
Dem Beispiel oben könnte man natürlich auch eine Funktion hinterlegen, die dann so aussähe:

person_construct($daten)

Wobei $daten ein Array von Informationen zur Person ist.
Kaum jemand würde Personendaten einzeln an eine Funktion übergeben oder täusche ich mich da?
Des weiteren würde auch in einer Klasse eine Überprüfung der einzelnen Einträge erfolgen (also ob leer oder nicht). Wird ein Element dieser Klasse hinzugefügt, müsste auch hier in der Klasse nachgearbeitet werden.

 

[mermshaus]

Ausschlag für den Thread war, dass ich in einem Essay über Debuggen las, man solle unnötiges Erstellen von Objekten vermeiden

Kann man den Artikel irgendwo einsehen? So aus dem Kontext gerissen, halte ich den Ratschlag für falsch.

Aber du hast schon ein wenig Recht. Die Tendenzen sind eindeutig in Richtung "alles muss eine Klasse sein" und zum Teil heftig übertrieben. Ich beobachte immer wieder, wie für eine ganz simple Aufgabe Klassen erstellt werden, obwohl es in PHP dafür oftmals einen eigenen fertigen Befehl gibt. Statt sich mir der Befehlsreferenz zu beschäftigen, wird etwas wildes zusammengecoded und als tolle Klasse rausgegeben.

Das heißt aber im Umkehrschluss nicht, dass nichts eine Klasse sein sollte. Hast du auch nicht behauptet, aber ich dachte, ich formuliere das noch mal.

Abstraktion hat nun mal ihren Preis, in wie weit du abstrahieren möchtest oder gar musst, musst du selber entscheiden.

OOP kann auch ein Gewinn sein. Ein Objekt wird etwa anders im Speicher angesprochen, als meinetwegen ein Array. Die Chance, dass ein Objekt beispielsweise als Funktionsparameter „sinnlos“ kopiert wird, ist praktisch null. Das kann je nach Anwendungsfall durchaus auch eine Effizienzsteigerung bedeuten.

Zugegeben, sowas kann man auch in eine Funktion bringen, der Aufwand ist dann aber schon so hoch, dass die Erstellung einer Klasse keinen Unterschied mehr macht.

Ja, die Erkenntnis habe ich in meinem letzten Post hervorzurufen versucht. OOP ist aus einem praktischen Bedürfnis heraus entstanden und nicht, weil jemand tolle theoretische Konzepte unbedingt in Programmiersprachen einbauen wollte. (Disclaimer: Ich weiß eigentlich nicht, wie OOP entstanden ist.)

Kaum jemand würde Personendaten einzeln an eine Funktion übergeben oder täusche ich mich da?

Beim „Konstruktor“ wäre das möglich, ja. Mir ging es darum, dass die Verwaltung zusammenhängender Daten in einem Array erheblich fehleranfälliger ist, da es keine Gewissheit gibt, dass der Zustand der Daten gültig ist. Auch ist ein kleiner Tippfehler $person['naem'] = 'Rudi Ratlos'; unter Umständen nachträglich nur sehr schwer zu entdecken, wohingegen $person->setNaem('Rudi Ratlos'); bereits beim Parsen der Datei einen Fehler wirft. Ein korrekt umgesetztes Objekt ist in vielerlei Hinsicht eine wesentlich robustere Datenstruktur.

Jede Funktion, der du eine Array-Datenstruktur übergibst, muss eigentlich vor der Verarbeitung explizit überprüfen, dass die Daten gültig sind. Bei einem Objekt ist dies praktisch auf syntaktischer Ebene sichergestellt.

 

[vanGoss]

Kann man den Artikel irgendwo einsehen? So aus dem Kontext gerissen, halte ich den Ratschlag für falsch.

Das eigentliche Zitat ist eigentlich unwichtig, es ging auch um einen völlig anderen Bereich(ich lese das Dokument nur zum Spass, weniger um es praktisch anzuwenden. Trotzdem hier:

The creation of new objects is moderately expensive on any system.

Danke auf jeden Fall für die Diskussion.
Rausgehört habe ich jetzt, dass das benutzen von Objekten, die nur eine Konstrukt und eine Printfunktion haben, die (fast) direkt hintereinander aufgerufen werden, ohne dass Objektdaten verändert werden, relativ sinnlos ist, und besser durch eine Funktion beschrieben wird(außer es gäbe Lesbarkeitsvorteile).


Trotzdem nochmal die Frage, ob ihr schonmal OOP bei einem Communityprojekt engesetzt habt, und wenn ja wo.

Gruß
vanGoss

 

[mermshaus]

Schau dir vielleicht mal ein PHP Framework an.

- Comparison of Web application frameworks - Wikipedia, the free encyclopedia

 

[vanGoss]

Schau dir vielleicht mal ein PHP Framework an.

- Comparison of Web application frameworks - Wikipedia, the free encyclopedia

ich möchte ja nicht vorgefertigte Klassen benutzen sondern selber welche machen
die Frage ist wofür?

noch Vorschläge?


Gruß
vanGoss

 

[struppi]

noch Vorschläge?

Was heißt noch Vorschläge? Du hast hier detailiert dargelegt bekommen, welche Konzepte hinter OOP stecken. Was willst du denn noch hören?

ich möchte ja nicht vorgefertigte Klassen benutzen sondern selber welche machen
die Frage ist wofür?

Das ist ein Grund für OOP, Klassen sind wiederverwendbar. Aber um "vorgefertigte" Klassen zu nutzen, musst du selber welche machen. Ausserdem ging es darum, dass DU die das mal anschaust um zu verstehen wie OOP in der Praxis aussehen kann.

Mir scheint es aber nicht, dass du ein grosses Interesse daran hast.

 

[crash]

Er versucht doch schon seit dem ersten Beitrag sich mit Händen und Füßen gegen OOP zu wehren.

Und so verschwendet er sinnlos Zeit in etwas, was mit Zend_Db, Doctrine, Propel usw. schon längst erledigt wäre (wie die meisten anderen auch).

 

[vanGoss]

Er versucht doch schon seit dem ersten Beitrag sich mit Händen und Füßen gegen OOP zu wehren.

Das stimmt so aber nicht?!?


Nun gut, danke für alle Antworten, dann gehe ich das alles durch und schau mir an, was ich brauchen kann.
Danke

Gruß vanGoss


PS:

Was heißt noch Vorschläge? Du hast hier detailiert dargelegt bekommen, welche Konzepte hinter OOP stecken.

Das Grundkonzept, auch die Wiederverwertbarkeit, habe ich IMHO einigermaßen verstanden, ich dachte nur beim Eröffnen dieses Threads, das jemand schreibt: "Ich hab vor nem Jahr ein Forum programmiert und da selbstständig Klassen für ein Kommentarsystem geschrieben".
Dann hätte ich da wieder Anregung gehabt, weil ich eben nicht weiß, was man für 'Kommentarsystem' einsetzen kann.
Jetzt sehe ich mir halt die Frameworks durch

 

[freak131]

oh man, sowas bietet auch nur die php community. ich kenne keinen ernst zunehmenden Entwickler aus dem java, php, python, ruby, ... umfeld der nicht nach oop pattern entwickelt. oop so in frage zu stellen ist schon fast dreist.

und selbstständig Klassen für ein Kommentarsystem geschrieben

hab ich im letzten jahr diverse male gemacht, für unterschiedlichste systeme - natürlich oop.

lesen und lernen:
Roter Grad - Clean Code Developer