am 11. August 2010
Die objektorientierte Programmierung hat ihren festen Platz in der Programmierung gefunden, zu groß scheinen die Vorteile um darauf zu verzichten. In PHP hingegen wird noch viel prozedural programmiert und ü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?
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.
Wer in Teams oder an großen Projekten arbeitet kann getrennt von anderen entwickeln, nur 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.
OOP? Nein danke!
Wer von der OOP überzeugt ist, braucht naturgemäß nicht mehr überzeugt werden – für alle anderen muten die üblichen Argumente für OOP eher kryptisch und abschreckend an.
Vor allem die berüchtigste 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 sind, “weil es ja so gut läuft”.
PHP ist 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 es nicht zu machen. Und “bekannterweise” kann man das mit PHP “doch mal schnell” umsetzen – “das kann doch nicht lange dauern”.
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 Seiten bleiben aber oft unabhängige Einheiten, anders als bei einer klassischen Applikation in der die Arbeiten aller Beteiligten in einem großen Programm zusammenfließen.
Die Realität abbilden? Wer 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 dauerhaft im Zugriff ist?
Nicht jeder programmiert als Wochenendaufgabe ein zweites Facebook oder ein komplexes CMS. PHP ist nicht umsonst eine Multiparadigmen-Programmiersprache.
Es lebe die OOP!
Objektorientierte Programmierung bietet auch und gerade unter PHP 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, 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 eine dokumentierte Lösung des Problems.
Eine langsamere Ausführungsgeschwindigkeit? Vergessen Sie es, der vielbeschworene 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?
Aber irgendwie wäre unser Job ja auch langweilig, wenn immer alles perfekt liefe 
)
