OOP (in PHP) - 3 Fragen

[dedlfix]

Hi!

ich entdecke gerade anhand dieses sehr guten Tutorials von Peter Kropff die tolle Welt von OOP in PHP. Das Problem was ich jetzt habe ist, dass in dem Text zwar alles super erklärt wird, aber wie man jetzt konkrete Probleme mit OOP umsetzt, steht eben nicht drin.

Er erklärt das anhand ziemlich abstrakter Beispiele. Das heißt, im wahren Leben sind seine Beispiele ziemlich konkret, aber beim Programmieren bildet man doch öfter mal Dinge ab, die man ohne die Programmierung gar nicht bräuchte oder erstellt Code zwar so, dass er das konkrete Problem erfüllt, aber an die Gegebenheiten der Computerprogrammierung angepasst ist.

Ich hab nicht alles gelesen, ich hab erstmal aufgehört, als ich den ersten groben Schnitzer fand. "Briefzustellen" ist bei ihm eine Klasse, die sowohl den Brief als auch das Zustellen enthält. Im wahren Leben ist das aber nicht so. Genauso wie sich eine Kuh nicht selbst melkt, also nicht sie die Methode "Melken" bekommt sondern der Bauer, versendet sich ein Brief nicht selbst. Der Brief ist also ein Objekt und die Post, die die Briefe zustellt, ein anderes. Methoden eines Objektes sollten immer Tätigkeiten sein, bei denen es akrtiv ist. Wenn es passiv etwas mit sich geschehen lassen soll, wird es als Parameter an eine Methode des aktiven Objekts übergeben.

Jedenfalls muss man als Programmierer in der Lage sein, die Hilfsmittel auch im abstrakten Zustand zu kennen und bei konkreten Aufgabenstellungen wissen, wie man diese am besten mit den gegebenen Mitteln umsetzt.

• Ich habe eine Klasse "page", die die Verwaltung der Seiten übernimmt. Diese hat verschiedene Methoden, unter anderem "load", mit der man eine bestimmte Seite in den Speicher lädt. Wo aber gehört denn die Funktion (ich meine nicht "Subroutine") zum Auslesen der Seite aus den GET-Parametern hin? In die Klasse? Oder einfach außerhalb in das Script?

Wenn du mit "Auslesen der Seite aus den GET-Parametern" meinst, wie dein Page-Objekt nun weiß, was der Client aufgerufen hat, dann ist das nicht Aufgabe des Page-Objekts, herauszufinden was es eigentlich sein soll. Stattdessen nimmt man einen Front-Controller, der die Eingabeparameter auswertet und entsprechend das passende Page-Objekt erstellt. Wenn du die Page-Klasse von den GET-Parametern abhängig machst, ist sie nicht mehr universell. Sie kann dann weder POST noch irgendwelche anderen Requests bearbeiten. Oder du baust das alles mit Fallunterscheidungen ein, wobei du wieder beim Programmierstil "Unstrukturierte Ablaufsteuerung" gelandet bist.

Wenn du es ordentlich machen willst - also schön gekapselt und wiederverwendbar -, brauchst du also eine gewisse Menge Overhead, der bei der "unstrukturierten Ablaufsteuerung" nicht benötigt wird.

• Und wo packt man die Umleitung auf Fehlerseiten hin?

Die lässt man ganz weg. Weiterleititis ist eine vermeidbare Krankheit. (Es gibt sinnvolle Anwendungen für Weiterleitungen, aber Fehlermeldungsseiten gehören nicht dazu.) Man gibt einfach die geforderte Seite aus. Im Fehlerfall kommt nicht der eigentliche Inhalt sondern der Ersatzinhalt zur Ausgabe. Ersatzinhalt kann auch eine Fehlermeldung sein, auch begleitet von einem entsprechenden Statuscode. Ersatzinhalt kann auch etwas sein, das dem Anwender hilft, trotzdem ans Ziel zu kommen, ihm eine Alternative bietet, anstatt ihn ob der Fehlermeldung achselzuckend zur Konkurrenz zu verlieren.

Sollte die Klasse selbstständig bei Fehlern statt der gewünschten die Fehlerseite laden, oder sollte sie nur einen Fehler zurückgeben und das Hauptprogramm lässt dann die Klasse die Fehlerseite laden?

Vermeide eierlegene Wollmichsau-Objekte. Sie sehen einerseits aufgrund ihrer vielen Features sehr nützlich aus, bedeuten jedoch andererseits einen erhöhten Erstellungs- und später Pflegeaufwand. In eine Page-Klasse würde bei mir nur die Aufgabe haben, die beim EVA-Prinzip der A-Teil hätte, also alles was mit Ausgabe zu tun hat. Das Besorgen der Daten und dabei auftretende Fehler zu behandeln ist Aufgabe des V-Teils. Anhand dessen Ergebnisses kann man dann entscheiden, welchen Inhalt das Page-Objekt zwecks Ausgabe bekommt - beispielsweise welches Template zu laden ist.

• Die letzte Frage, die eigentlich aus den anderen beiden hervorgeht ist, ob man sowas wie Session-Initialisierung, erstellen der page-Instanz, usw. in die Klasse CMS* als Methode packen sollte, die dann im Hauptprogramm aufgerufen wird, oder ob das einfach im Hauptprogramm stehen sollte.

Session-Initialisierung wäre vielleicht eine Aufgabe des Front-Controllers, wenn zum Ermitteln, was verarbeitet werden soll auch Session-Daten benötigt werden. Vielleicht braucht es auch erst der Verarbeitungsteil. Und manchmal hat man mehrere Stellen, die auf Session-Daten angewiesen sind oder solche erzeugen. Dann sollte man die Session-Verwaltung als eigenen Programmteil erstellen.

Wenn du was komplexes machen willst, kannst du ruhig erst einmal versuchen, etwas selbst zu erfinden, um dabei auch die Schwierigkeiten dieses Weges kennenzulernen. Und dann kannst dir mal vorhandene Frameworks ansehen, die zum Beispiel nach dem MVC-Muster aufgebaut sind. Üblicherweise hat man genug mit der Implementierung der eigenen Geschäftslogik zu tun, so dass es hilfreich ist, wenn für die ganzen kleinen Nebentätigkeiten bereits vorhandene Lösungswege genutzt werden können. Selbst wenn du lieber selbst etwas erstellen willst, lohnt sich der Blick auf ein Framework, um Inspirationen für den Aufbau des eigenen Projekts zu bekommen.

Lo!