Alles ist eine Klasse25 Aug

Wer kennt das nicht: Man hat eine wunderbare Benutzerklasse geschrieben. Sie beinhaltet sämtliche Eigenschaften, die ein Benutzer so besitzen könnte innerhalb der Applikation: Name, eMail-Adresse, Passwort, Rechte. Klingt toll – könnte aber besser sein!

Die Faulheit lässt die stets hoch gelobte Objektorientierung 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 Objekte von eigenen Klassen sein.

eMail-Adresse

Die eMail-Adresse könnte als eigene Klasse “Email” verschiedenste Methoden oder Eigenschaften aufweisen: Beispielsweise möchte man eine eMail-Adresse darauf prüfen, ob sie korrekt zu sein scheint – was liegt da näher, als diese Aufgabe nicht eine Email-Klasse übernehmen zu lassen? Die User-Klasse? Weit gefehlt. Aus der eMail-Adresse könnte beispielsweise auch der Host gelesen werden.
Dass die Klasse für jede in der Anwendung vorkommende eMail-Adresse neu instanziert wird kommt der Objektorientierung doch gerade recht: Denn schließlich soll es ruhig mehrere oder gar viele Objekte einer Klasse geben.

Benutzerrechte

Dieser Aspekt einer Benutzerverwaltung ist so komplex, dass ihm sogar gleich mehrere Klassen gebühren sollten. Ein Benutzerrecht kann sich bspw. auf einen Applikations-Bereich beziehen und entsprechende Informationen beinhalten. Oder Informationen zum entsprechenden Datenbank-Eintrag, in dem das Recht vermerkt ist. Es wären genauso Gruppen vorstellbar, die mehrere oder viele Rechte in sich vereinen. Da winken doch schon super Einsatzbereiche verschiedenster Entwurfmuster. Der Benutzer vereint schließlich die gesamten Rechte in einer sammelnden Klasse, z.B. “Rights“.

Adresse

Auch hier gibt es mehrere Informationen: Herkunftsland (oder gar Kontinent?), Bundesstaat (falls existent?), Stadt, Straße, Hausnummer, Postleitzahl oder vielleicht Kreis oder Regierungsbezirk? Hier gäbe es je nach Anwendungsfall auch viele Möglichkeiten und einen sinnvollen Einsatz einer eigenen Klasse.

Passwort

Vor nicht all zu langer Zeit hatte ich einen Artikel über ein Loginsystem. Dabei gab es verschiedene Zustände des Passworts: Das Passwort in völliger Rohform als String, als sicherer Hash in der Datenbank oder als Hash mit einem generierten Seed. Alles wäre in einer Klasse vereinbar – zudem könnte die Klasse noch andere Aufgaben erledigen, je nach Auslegung der Klasse (Zurücksetzen des Passworts, Generierung von neuen Passwörtern, Verschlüsselung). Auf jeden Fall alles nicht Aufgaben der Benutzerklasse, die alles in sich sammeln und deligieren sollte.

Die Elternklasse – in dem Fall Benutzerklasse – muss nur einer Fassade ähnlich entsprechende Anfragen weiterleiten bzw. verarbeiten.
Weiterhin ist auf die Auslegung einer Klasse zu achten! Eine Passwort-Klasse könnte ein Passwort als einzelnes Passwort betrachten (was sie meiner Meinung nach tun sollte) oder eben Passwörter in ihrer Gesamtheit. Im ersten Fall würde die Passwort-Klasse beispielsweise über eine Verschlüsselungsklasse das Passwort entsprechend verschlüsseln und direkten Zugriff nicht so einfach ermöglichen. Im zweiten Falle könnte die Klasse neue Passwörter an sich generieren. Eine Klasse, die aber ein Passwort repräsentiert und neue Passwörter generieren kann, wäre nicht in meinem Sinne der Objektorientierung.

Julian.