Mittwoch, 11. August 2010

OOP unter PHP?

Ach, wie doch die Zeit vergeht, dieser Artikel erschien ursprünglich im August 2010 in dem Blog phphatesme.com. Das Blog hat inzwischen einen Nachfolger mit dem allgemeineren Namen thewebhatesme.com auf dem die meisten Artikel noch erreichbar sind. Der Beitrag hatte damals eine durchaus kontroverse Diskussionen ausgelöst - da ich solche Diskussionen sehr schätze, habe ich diesen Beitrag ein klein wenig entstaubt, um ihn vor dem Vergessen zu bewahren und ihm (zeitlich korrekt eingeordnet) in dieses Blog ein dauerhaftes Refugium zu gewähren.


OOP unter PHP?


Die objektorientierte Programmierung hat ihren festen Platz in der Programmierung gefunden, zu groß sind die Vorteile, um darauf verzichten zu können. In PHP hingegen wird auch durchaus heute noch prozedural programmiert und manchmal sogar noch über den Sinn oder Unsinn der Objektorientierung gestritten. Haben Sie vielleicht Kollegen, die den Segen der OOP noch nicht verinnerlicht haben? Oder sind Sie vielleicht selbst noch gar nicht von der OOP überzeugt?

Die Versprechen der OOP


Die Kapselung von Daten, Steuerung der Sichtbarkeit und der Schutz von Methoden und Attributen. Vererbung bis hin zu Mehrfachvererbung, Überladung, Polymorphismus und endlich, endlich auch Persistenz im Gegensatz zu dem kurzen Aufflackern der Daten in einer Funktion. Nicht zu vergessen die Behandlung von Exceptions.

Auch wenn PHP nicht alles davon in Vollendung bietet, ist PHP seit Version 5 eine Sprache, mit der sehr gut objektorientiert entwickelt werden kann. Die in diesem Zusammenhang immer noch zitierte Version 4, die OOP tatsächlich eher stiefmütterlich behandelte ist schon lange Geschichte, so wie Telefone mit Wählscheiben, vierstellige Postleitzahlen oder die immer wieder beschworene Langsamkeit von Java.

Wer in Teams oder an großen Projekten arbeitet, kann dank OOP getrennt von anderen entwickeln, lediglich Schnittstellen müssen bekannt gemacht werden. Wie Klassen intern funktionieren, spielt keine Rolle mehr. Die Wartung von Code wird erleichtert, interne Änderungen haben keine Auswirkungen nach außen. Klassen können wiederverwendet werden, in Folge-Projekten kann die Entwicklungszeit reduziert werden.
Die Realität kann als Vorbild in Klassen und Objekten abgebildet werden – nicht nur bei der Programmierung, sondern bereits bei der Analyse und beim Design.

Überzeugen die Argumente der OOP?


Wer von der OOP überzeugt ist, braucht naturgemäß nicht mehr überzeugt werden – für alle anderen muten diese üblichen Argumente pro OOP eher kryptisch und abschreckend an.

Vor allem die berüchtigtste aller Aussagen “Alles ist ein Objekt”, hat etwas von der stereotypen, aber unverständlichen Frage “Sind Sie außer Gefahr” aus dem Film “Der Marathon Mann” als Dustin Hoffman auf einem Zahnarztstuhl gefoltert wird.

Wie sieht die Entwicklung mit PHP (oft genug) aus?


Wenig Zeit, vage und sich ändernde Anforderungen. Einmann-Entwicklung von der Analyse bis zur Umsetzung. Kurzfristig und nur als Zwischenlösung gebraucht – dann aber jahrelang im Einsatz “weil es ja so gut läuft”.
PHP ist oft genug der Notnagel, mit dem “mal eben” Anforderungen umgesetzt werden sollen, die mit anderen Systemen erst gar nicht angegangen werden – sei es, dass zu wenig Ressourcen vorhanden sind oder das ganze eben nichts kosten darf, aber eben doch zu wichtig ist, um nicht gemacht zu werde. Und “bekannterweise” kann man das mit PHP “doch mal schnell” umsetzen – “das kann doch nicht lange dauern” und „da gibt es doch schon fertige Skripte bei Google“.

Wer alleine arbeitet, braucht seine Funktionen und Variablen nicht zu kapseln. Ein unerlaubter Zugriff auf den eigenen Code durch andere stellt kein Problem dar, wenn jeder Entwickler seine eigenen Seiten oder ganze Bereich entwickelt. Die Absprache mit den Kollegen beschränkt sich auf Datenbankwerte oder Parameterübergaben zwischen Seiten. Ein Konflikt auf Code-Ebene ist ausgeschlossen.
Webseiten ergeben ein großes Ganzes, die einzelnen Seiten selbst bleiben aber oft unabhängige (durchaus Objekt-ähnliche) Einheiten - ganz anders als bei einer klassischen Applikation in der die Arbeiten aller Beteiligten in einem großen Programm zusammenfließen.
Die Realität abbilden? Wer bitte sagt, dass die Realität für einen Prozess ideal ist? Wie sollen zahlreiche von der Realität hergeleitete Objekte “Kundenbetreuer”, “Kunde”, “Bestellung” von Seite zu Seite weitergegeben werden? Serialisierung macht nicht wirklich viel Spaß.
Wartbarkeit oder Wiederverwendung von Code? Auch Funktionen und includes lassen sich wiederverwenden. Persistenz? Wozu wenn sich alles sowieso auf einer Ebene befindet und damit problemlos im Zugriff ist?

Nicht jeder programmiert als Wochenendaufgabe ein zweites Facebook oder ein komplexes CMS. PHP ist nicht umsonst eine Multiparadigmen-Programmiersprache.

Gerade deshalb: Es lebe die OOP!


Objektorientierte Programmierung bietet auch und gerade unter PHP zu viele Vorteile, nur sind die gebetsmühlenartig wiederholten Argumente unpassend und schrecken gerade die ab, die sie erreichen wollen.

OOP bietet eine einfache Möglichkeit Code effizient in kleine und kleinste Module zu unterteilen. Komplexe Strukturen lassen sich aufbrechen und entscheidend vereinfachen. Bereits kurzer Programmcode kann sinnvoll unterteilt werden und damit die Lesbarkeit (auch und insbesondere) des eigenen Codes verbessert werden.
Funktionen sind beschränkt, nur ein Parameter kann zurückgegeben werden – auf Objekte kann immer wieder zugegriffen werden und sie können viele Parameter zur Verfügung stellen. Klassen sind eigentlich so etwas wie “Mega-Funktionen” – nur hätte diesen Namen erst recht niemand gekauft.
Das Testen von Code, der so modularisiert ist, eindeutige Schnittstellen hat und für sich steht, ist wesentlich einfacher.
Die Festlegung der Sichtbarkeit von Methoden und Attributen mit public, private oder protected dient nicht nur dem Schutz gegen wilde Kollegen, sondern ist auch Dokumentation bei dem Monate später erfolgenden Blick auf den dann schon wieder verstaubten und vergessenen Code (vergleiche “PHP objektorientiert” von Peter Lavin).
Die Aufteilung einer Aufgabe in Klassen, Methoden und in Attribute dient nicht nur einer abstrakten Modularisierung, sondern macht den Code lesbarer und ist selbst eine dokumentierte Lösung des Problems.

Eine langsamere Ausführungsgeschwindigkeit? Vergessen Sie es, der Overhead ist gering und Optimierungsmöglichkeiten gibt es an anderen Stellen genug.

Fazit


Es lebe die OOP in PHP, nur die Hochglanzbroschüre für die Anpreisung sollte überarbeitet werden. 
Oder wie halten Sie es mit der OOP?

Keine Kommentare:

Kommentar veröffentlichen