// der php hacker

// archiv

“Alles ist eine Klasse”

Geschrieben am 18. Jan 2009 von Cem Derin

bricks

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.

Geschrieben in Entwicklung, Theorie 7 Kommentare

#001
21. Jan 2009

Also bei Email, Passwörter und Rechten sehe ich das genau so. Aber Namen und Adressen würden bei mir nicht in Frage kommen(jedenfalls war es bisher so, man weis ja nie was einem noch so einfällt).


#002
22. Jan 2009
unset

Naja, sowohl der Name als auch die Adresse sind Informationen, die sich wiederum aus weiteren kleineren Einzelstücken zusammensetzen. Ausserdem: “Splitters Can Be Lumped Easier Than Lumpers Can Be Split”.


#003
24. Jan 2009

Das ist richtig. Ich hatte bisher aber nie Verwendung dafür. Sollte ich aber einmal einen für mich passenden Fall finden, könnte ich mir auch vorstellen diesen Part weiter auszulagern.

#004
31. Jan 2009

[...] es nicht. Aber es gibt Möglichkeiten, den Effekt zu erzielen. Ansätze gibt es da mehrere: “Alles ist eine Klasse” und ein kleiner Hack unter Zuhilfenahme eines eigenen Error-Handlers sind nur zwei davon. [...]

#005
25. Aug 2009

[...] wieder einmal völlig unter den Tisch kehren. Denn alles ist eine Klasse, wie ich dank dem phpHacker lernen durfte. Die meisten dieser Eigenschaften können anstatt als einfache Strings wiederum [...]

#006
12. Mrz 2010

[...] Alles ist eine Klasse! __________________ // der php hacker twitter.com/unset Usertreffen 2010 in Berlin! Wann Kannst du? [...]


#007
12. Mrz 2010

theoretisch verstehe ich diesen standpunkt. praktisch, als jemand der nur kleine skripte / projekte bearbeitet – habe ich meine bedenken.

denn wenn es nur minimaler aufwand bedeutet eine kleine seite umzusetzen, wieso sollte ich für alles eine eigene class entwerfen?

// kommentieren

// senden
theme von mir, software von wordpress, grid von 960 grid system. funktioniert in allen browsern, aber der safari bekommt das mit der schrift am schönsten hin.