Vorweg die gute Nachricht: Objektorientierung hat sich in der PHP-Welt durchaus durchgesetzt. Große Projekte werden immer öfter Objektorientiert angegangen, es werden Design Pattern umgesetzt und PHP spielt einem mit jeder neuen Version mehr und mehr in die Hände. Frameworks wie das Zend Framework oder CakePHP tragen ihren Teil oftmals dazu bei.

Kommen wir aber zur schlechten Nachricht: Die Klassenabstraktion wird oftmals nicht sehr weit geführt. Oft werden bestimmte Untermengen nicht mehr Objektorientiert strukturiert, sondern man verfällt innerhalb der ersten Klasse schnell dazu, Eigenschaften primitiv abzubilden.

Als Negativbeispiel kann man hier die in vielen Projekten vorkommende User-Klasse anführen. Ein Benutzer hat eine Reihe von grundlegenden Eigenschaften:

• eMail-Adresse
• Passwort
• Benutzerrolle/n

Das sind wahrscheinlich die Daten, die jeder Benutzer innerhalb einer Webapplikation haben sollte. Darüberhinaus kommen aber noch eine Reihe weiterer, je nach Zweck der Software:

• Vorname
• Nachname
• Adresse

Diese Liste kann man endlos weiterführen, wir wollen uns aber mal mit diesen Daten begnügen. Meistens werden diese Daten in Properties des Users primitv gespeichert. Warum auch nicht, denk man sich vielleicht?!

Kommen wir also nun zum Titel dieses Artikels und wenden ihn auf diese Daten an: Ich plädiere dafür, diese Daten alle in eigenen Klassen abzubilden. Warum?

eMail-Adresse

Eine eMail-Adresse sollte aus mehreren Gründen in eine eigene Klasse gekapselt werden. Nehmen wir an, wir wollen die eMail-Adresse verschlüsseln um sie gegen Harvester abzusichern. Oder wir wollen bestimmte Informationen wie den Host und ähnliches herausfiltern. Das sind alles Operationen, die auf die eMail-Adresse angewandt werden. In schlecht bzw. nicht sauber strukturierter Software lägen diese Methoden meist innerhalb des Models “User”.

Passwort

Das Passwort ist ebenfalls eine Entität, auf die wir sicherlich früher oder später zugreifen wollen: Wir wollen es ändern, zurücksetzen, anders verschlüsseln, etc. Wieder Methoden, die nichts im User verloren haben.

Benutzerrollen

In der Regel wollen wir nicht nur die Information haben, welche Rollen dem Benutzer zugewiesen sind, sondern wollen auch mit diesen arbeiten. Wir wollen dem Benutzer neue Rollen zuweisen oder auch alte entfernen. Wenn wir diese Abfragen machen, bekommen wir direkt die Rollen-Objekte und nicht nur blanke IDs aus der Datenbank.

Name

Der Name des Benutzers ist ebenfalls ein interessantes Attribut. Manchmal wollen wir den Vornamen, manchmal wollen wir den Nachnamen. Manchmal beide, manchmal mit Anrede. Eine ganze Menge Dinge also, die wir mit dem Namen anstellen können. Da macht es nur Sinn, diesen ebenfalls in eine eigene Klasse auszulagern. Der “Name” setzt sich aber wieder aus den Klassen “Vorname” und “Nachname” zusammen.

Adresse

Der Benutzer hat eine Adresse. Eine Adresse besteht aber aus Straße, Hausnummer, ggf. einem Zusatz, einer Postleitzahl (jaja, in Irland nicht, ich weiß Mario ) eine Stadt, ggf. einem Bundesland o.ä. und einem Land. Eine ganze Menge Dinge, die sich auch immer unterschiedlich zusammensetzen, unterschiedlich abgekürzt werden können und so weiter. Aber der Benutzer hat immer ein Bündel davon. Daher gibt es die Klasse Adresse. Diese hat eine Reihe von Unterklassen: Die Straße, die sich aus Straßenname, Hausnummer und Zusatz auszeichent, die Stadt, die sich aus PLZ und Stadt zusammensetzt sowie das Bundesland und das Land. Alles eigene Klassen.

Aggregieren

Natürlich müssen Methoden vorgehalten werden, um zusammengehörende Daten aus einer Menge von Klassen zu aggregieren. Diese Methoden gehören immer in die jeweilige Unterklasse. Will man die komplette Adresse (für zum Beispiel einen generierten Briefkopf) so gibt es eine Aggregatsmethode in der Überklasse (Also User), die Adresse ohne Name wird von der Adressklasse zusammengebaut, während die Straße mit Hausnummer und Zusatz von der Straßenklasse zusammengebaut wird.

Foto von Daniel Wildmann.