Theorie und Praxis OOP

[pl]

Interfaces werden in Klassen implementiert, nicht geerbt, von einem Interface erben können nur Interfaces.

Das mag in PHP so sein. In Perl jedoch kann ich das auch anders machen, deswegen darf ich das immer noch Interface nennen. Ich kann ein IF z.B. so gestalten, dass es gar nicht vererbt wird, also so, dass Methoden eines IF nur dann ausgeführt werden, wenn sie vorhanden sind. Oder als Funktionsreferenz definiert sind.

Mit Letzterem setze ich das Entwurfsmuster des Decorators um: Einer Subklasse wird zur Laufzeit ein beliebiges Interface zugewiesen. Z.B. weise ich einer Seite bzw. Klasse (Bindung: URL <=> Class) das interface=comment zu und schon können Besucher Kommentare zu genau dieser Seite verfassen.

Weißt Du, das eine ist die Theorie und das andere ist die Praxis. Warum überhaupt Klassen? Die Vererbung ist doch auch nur einer von vielen Aspekten. Wirklich interessantere Aspekte sind eher wirtschaftlicher Natur, gehen z.B. in Richtung Qualitätssicherung, Teamarbeit und Kostensenkung.

So hat mein FW Subklassen hauptsächlich deswegen, weil die Klasse die Frage zur Templatebeschaffung einer Seite regelt. Die Dialektik von Eigenschaften und Methoden: Eine Eigenschaft beinhaltet den Dateinamen, eine Methode holt das Template.

Sowas wird erst richtig interessant in der Implementierung einer Volltextsuchfunktion. Zu durchsuchen seien Title, Description und Body. Während die ersten beiden Eigenschaften als Attribute in der Konfiguration zu finden sind, muss der Body erst beschafft werden. Also schnappen wir uns das class= Attribute und erstellen ganz einfach eine Instanz für die in class= festgelegte Subklasse. Und nun müssen wir nur noch eine der im FW-Interface definierten Methoden aufrufen, welche für die Beschaffung des Body zuständig ist. Fertig.

Dies und das und Weiteres ist praktisch angewandte OOP. Aber das wirst Du wahrscheinlich nie verstehen.

Schönen Tach auch.