OOP (in PHP) - 3 Fragen

[Take]

Moin,

Hach, mit deiner Antwort kann ich schonmal mehr anfangen, als mit der von hotti (nix gegen dich hotti, aber ich glaube, du kannst einfach nicht gut erklären :D). Dankeschön!

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.

*freu* Genau das hab ich mich beim Lesen auch gefragt! Das zeigt auf jeden Fall, dass ich was verstanden habe.

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

Das hab ich bei hotti glaub ich auch rausgelesen. Und dieser Front-Controller stellt dann wahrscheinlich eine statische Methode dar, die einmal aufgerufen wird und dann den Ablauf steuert, oder?

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.

Ich merke: das Wort "Umleitung" ist doof gewählt, siehe meine Antwort auf hottis Post.

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.

Ok, hab mich mal kurz informiert, was das EVA-Prinzip überhaupt ist. Bei einem CMS wäre also die Eingabe die GET/POST-Parameter. Der Front-Controller (ich übernehme einfach mal deine Begriffe, hoffentlich richtig :D) entscheidet auf deren Basis, was zu tun ist und ruft entsprechend die Methoden der einzelnen Klassen (z.B. "page", "template", usw.) auf. Das Ergebnis dieses Prozesses (Seiteninhalt an Template übergeben, usw.) wird dann (vom Front-Controller) an den Browser gesendet. Soweit OK?

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.

Puh, viel Arbeit. Da hab ich mir ja was vorgenommen :D Jetzt ist erstmal Gute Nacht :)

Vielen Dank dedlfix, hast mir sehr geholfen!

Gruß,
Take