Daniel Thoma: Klassen, Methoden, Objekte

Beitrag lesen

Hallo Andre,

Eine Klasse hast Du schon mal vergessen. Diese Mitarbeiter, Kunden und der Admin hängen ja nicht einfach so in der gegend rum, sondern es gibt irgend ein System, zu dem sie gehören. Das solltest Du als zentrales Objekt haben.
Ich würde also das in etwa so modelieren:

class System {
  Admin getAdmin();
  UserSet getUsers();
}

class UserSet extends AbstractSet<AddableUser> {
  void add(AddableUser newUser, User user);
}

interface User {
  String getName();
  String setName(String name, User user);
}

interface AddableUser extends User {

}

interface PasswordUser extends User {
  boolean checkPassword(byte[] checksum);
  void setPassword(String password, byte[] oldChecksum, User user);
}

class Admin implements PasswordUser {

}

class Mitarbeiter implements PasswordUser, AddableUser {

}

class Kunde implements AddableUser {

}

In den Klassen müssen die Methoden der Interfaces natürlich implementiert werden.
AbstractSet<AddableUser> ist eine ungeordnete Menge von Objekten die AddableUser implementieren. Evtl. ist es auch sinnvoll Kunden und Mitarbeiter in getrennten listen zu verwalten.
Die set- und add-Methoden haben ein User-Argument für den Benutzer, der die Operation ausführt um Zugriffsrechte prüfen zu können.
Möglicherweise macht man das natürlich in einer anderen Schicht. Mir ging es auch mehr darum eine mögliche Strukturierung mit Klassen und Schnittstellen aufzuzeigen.

Das Problem dieses Ansatzes ist es, dass Benutzer ihren Status nicht ändern können. Ich kann also z.B. aus einem Kunde keinen Benutzer machen. Wenn man das will, müsste man das ohne Vererbung modelieren und einem Benutzer z.B. ein oder mehrere Rollenobjekte zuordnen, die für die Rollenspezifischen Eigenschaften zuständig sind.
 Außerdem könnte man sich überlegen, ob die Sonderrolle des Admins überhaupt sinnvoll ist und ob man den nicht lieber auch in der Benutzerliste verwaltet.

Grüße

Daniel