Klassen, Methoden, Objekte

[Andre]

Hallo,

Ich möchte aus den folgenden Objekten und Methoden, Klassen erstellen. Dabei weiß ich nicht welche Möglichkeit die Richtige ist. Im Netz habe ich für beide Möglichkeiten Indizien gefunden.

3 Objekt:

• Admin
• Mitarbeiter
• Kunden

6 Methoden

• Admin ändert sein Passwort
• Mitarbeiter anlgegen durch den Admin
• Mitarbeiter loeschen durch den Admin
• Mitarbeiter ändert sein Passwort
• Kunde anlgegen durch den Admin
• Kunde loeschen durch den Admin

1. Möglichkeit: (Alle Aktionen des Objekts Admin sowie des Mitarbeiters sind jeweils in einer Klasse zusammengefasst.)

Klasse Admin

• Admin ändert sein Passwort
• Mitarbeiter anlgegen durch den Admin
• Mitarbeiter loeschen durch den Admin
• Kunde anlgegen durch den Admin
• Kunde loeschen durch den Admin

Klasse Mitarbeiter

• Mitarbeiter ändert sein Passwort

2. Möglichkeit: (Eine Klasse ist die Zusammenfassung von Methoden die ein Objekt verändert? Also das Objekt Admin, Mitarbeiter und Kunde.)

Klasse Admin

• Admin ändert sein Passwort

Klasse Mitarbeiter

• Mitarbeiter anlgegen durch den Admin
• Mitarbeiter loeschen durch den Admin
• Mitarbeiter ändert sein Passwort

Klasse Kunde:

• Kunde anlgegen durch den Admin
• Kunde loeschen durch den Admin

Oder ist das beides richtig und möglich?

Vielen Dank für eure Hilfe.

[Jörg Peschke]

Hallo,

Oder ist das beides richtig und möglich?

Möglich ist natürlich beides.

Da die Idee hinter der Objektorientierung ja ist, real existierende Objekte nachzubilden, würde ich etwas mehr zu Variante drei tendieren:
So hast du nämlich in der Realität UND in deiner Software drei Objekte, einen Kunden, einen Admin und einen Mitarbeiter.

In der Variante 1 verkümmert der Kunde dann von einem eigenständigen Objekt zu einer angeflanschten Eigenschaft des Admins....ob ihm das wohl gefällt? ;)

Ist aber auch ein bisschen Geschmackssache ;)

Ciao,
Jörg

[Rouven]

Hi,

Da die Idee hinter der Objektorientierung ja ist, real existierende Objekte nachzubilden, würde ich etwas mehr zu Variante drei tendieren:

Hinter der Objektorientierung steht auch der Gedanke, dass man Objekte mit den Methoden ausstattet, die zu _ihrer_ Bearbeitung erforderlich sind. Das soll gewährleisten, dass man Objekte intern anders implementieren kann, ohne dass andere Objekte davon betroffen sind. Wenn du also in deinem Kunden den Namen nicht als String sondern als Zahlenfolge speicherst, soll der Admin trotzdem noch über getName() an den Namen kommen, OHNE zu wissen wie es denn jetzt abgelegt ist.
Demnach sollte es so sein, dass:

• Admin-Objekt: kann das Passwort ändern
• Mitarbeiter: kann angelegt und gelöscht werden sowie sein Passwort ändern
• Kunde: kann angelegt und gelöscht werden

Das kann man dann auch schon fast in eine Hierarchie packen, so dass man die Methoden einmal im "Oberobjekt" Person implementiert, sofern sie für alle 3 Objekte gleich sind. Siehe hierzu auch der Artikel zur Objektorientierung in der Wikipedia.

MfG
Rouven

[Daniel Thoma]

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