Hauptmenü

Untermenü

OOP mit PHP5

1. Ein Wort in eigener Sache

Warum macht sich eigentlich jemand die Mühe und verfasst noch mal eine Einführung zum Thema "Objektorientierte Programmierung mit PHP 5"? Davon gibt es doch Massen im Internet. Nun, ursprünglich hatte ich das gar nicht vor. Als ich Ende 2005 anfing, mich intensiv mit diesem Thema zu beschäftigen, musste ich feststellen, dass eigentlich fast alle Anleitungen zu diesem Thema für Nicht-Informatiker kaum verständlich sind. Ein paar Beispiele gefällig?

"Das Ablegen einer Referenz auf ein anderes Objekt in einer Instanzvariablen eines Objektes nennt man Aggregation."
"Leitet ein Objekt einen Methodenaufruf an ein aggregiertes Objekt weiter, so spricht man von Delegation." [Quelle: Sebastian Bergmann, Professionelle Softwarentwicklung mit PHP5]
"Klassenmember oder -methoden als statisch zu deklarieren macht diese zugänglich, ohne dass man die Klasse instantiieren muss. Auf ein als statisch deklariertes Member kann nicht mit einem instantiierten Klassenobjekt zugegriffen werden." [Quelle: Handbuch PHP, Kapitel Klassen und Objekte (PHP 5)]

Alles klar? Begriffen? Kein Wunder! Selbst ich musste des Öfteren das eine oder andere nachschlagen. Zur Entschuldigung von Sebastian Bergmann sei gesagt, der schreibt nicht nur so, der redet auch so. Habe ihn mal auf einem Multimediatreff in Köln kennen gelernt. Außerdem richtet sich sein Werk ausdrücklich nicht an blutige Anfänger. Also darf er das. Beim PHP-Handbuch dagegen sehe ich das ein wenig anders. Egal, sei's drum.

So habe ich mir denn mal die Mühe gemacht, dieses Informatiker-"Deutsch" für euch zu übersetzen und in eine für Anfänger einigermaßen verständliche Form zu bringen. Darum gibt es denn nun eine weitere Einführung in die Objektorientierte Programmierung mit PHP5.

2. Warum Objektorientierte Programmierung?

Um diese Frage zu beantworten, muss ich erst mal auf die unterschiedlichen Programmierstile eingehen, die in PHP möglich sind. Das sind einfach gesagt, deren drei. Bitte verwechselt das nicht mit dem so genannten Programmierparadigma. Auch weise ich wie so oft darauf hin, dass die folgenden Begriffe meinem Hirn entsprungen sind.

Unstrukturierte Ablaufsteuerung

Dies ist der klassische Anfängerstil. Nicht böse sein, auch bei mir lief es zu Beginn so. Man fängt oben an und "programmiert" sich dann nach unten durch. Die gesamte Steuerung erfolgt ausschließlich über Bedingungen. Die Nachteile sind offensichtlich. Dieser Code wird für eine ganz bestimmte Aufgabe entwickelt, und nur dafür! Man kann ihn nicht für andere Projekte einsetzen. Wenn innerhalb der Programmierung etwas mehrmals erledigt werden soll, so muss der entsprechende Code dupliziert und angepasst werden. Änderungen dieser Abschnitte haben Auswirkung auf alle(!) relevanten Codeteile.

Strukturierte und funktionsbasierte Steuerung

Dieser Stil ist bereits ein gewaltiger Fortschritt und erfahrungsgemäß die nächste Stufe auf der Evolutionsleiter der Programmierung. Hier werden alle wichtigen Aufgaben in Funktionen ausgelagert, die man dann über entsprechende Parameter ansteuert. Der Vorteil ist offensichtlich. Ändern sich grundsätzliche Dinge, so muss man nur noch die Funktionen umschreiben und alles läuft. Die Nachteile sind trotzdem noch gravierend. Auch Funktionen sind meist für spezielle Aufgaben entwickelt worden und können in anderen Projekten nur durch Anpassungen(!) wieder verwendet werden. Und bei größeren Projekten mit verschiedenen Entwicklern endet das ganz schnell in einem riesigen Tohuwabohu.

Objektorientierte Programmierung (OOP)

Um die oben beschriebenen Nachteile zu umgehen, setzt man die Objektorientierte Programmierung ein. Sie ermöglicht es, immer wiederkehrende Aufgaben in so genannten Klassen zu bündeln. Für den Benutzer ergeben sich bei sauberer(!) Programmierung daraus gewaltige Vorteile, auf die ich gleich eingehen werde.

3. Was benötigt man für Objektorientierte Programmierung?

Erfahrung und entsprechende Vorkenntnisse in der strukturierten und funktionsbasierten Programmierung. Es gibt zwar immer wieder Leute, die behaupten, dass für Einsteiger die OOP besonders leicht zu lernen sei, da dieses Prinzip selbsterklärend ist. Ich persönlich habe da aber große Zweifel. Also, wenn ihr Anfänger seid und noch nicht mal strukturiert mit Funktionen programmieren könnt, so lernt doch bitte erst mal das und kommt dann wieder.

4. OOP - Der Stein der Weisen?

Nein! Nicht alles, was man programmieren kann, muss objektorientiert sein. Für ganz spezielle Aufgaben ist die normale prozedurale Vorgehensweise oft einfacher, besser und schneller. Denn bei der reinen OOP wird eigentlich immer ein so genannter "Overhead" erzeugt, also eine Art von objektorientiertem Wasserkopf. Man kann jetzt wieder trefflich darüber streiten, aber meine persönliche Meinung ist, dass man OOP nicht um der OOP Willen einsetzen sollte.

5. Beispiele

Aus Platzgründen werde ich hier nur Ausschnitte aus meinen Beispielen präsentieren. Wer es genau wissen will, lade sich doch bitte die funktionsfähigen Codeschnipsel rechts unter Beispiele herunter.

weiter zum nächsten Abschnitt