Kein wirkliches Problem ...
Ich sehe kein Problem mit User.isAdmin(). Ich bevorzuge es auf jeden Fall so etwas wie PermissionManager.userHasPermission(user, permissions.ADMIN), was im heiligen Namen von SRP den Code weniger klar macht und nichts von Wert hinzufügt.
Ich denke, SRP wird von einigen ein wenig zu wörtlich interpretiert. Ich denke, es ist in Ordnung, noch besser für eine Klasse, eine reichhaltige Oberfläche zu haben. SRP bedeutet lediglich, dass ein Objekt alles an Mitarbeiter delegieren muss, was nicht in seine alleinige Verantwortung fällt. Wenn die Administratorrolle eines Benutzers mehr als ein boolesches Feld ist, ist es möglicherweise sinnvoll, das Benutzerobjekt an einen PermissionsManager zu delegieren. Das bedeutet aber nicht, dass es für einen Benutzer auch keine gute Idee ist, seine isAdminMethode beizubehalten. Tatsächlich bedeutet dies, dass Sie den Code, der das Benutzerobjekt verwendet, ändern müssen, wenn Ihre Anwendung von einfach zu komplex wechselt. IOW, Ihr Kunde muss nicht wissen, was es wirklich braucht, um die Frage zu beantworten, ob ein Benutzer ein Administrator ist oder nicht.
... aber warum willst du das wirklich wissen?
Das heißt, es scheint mir, dass Sie selten wissen müssen, ob ein Benutzer ein Administrator ist, es sei denn, Sie können eine andere Frage beantworten, z. B. ob ein Benutzer eine bestimmte Aktion ausführen darf, z. B. das Aktualisieren eines Widgets. Wenn dies der Fall ist, würde ich es vorziehen, eine Methode in Widget zu haben, wie zum Beispiel isUpdatableBy(User user):
boolean isUpdatableBy(User user) {
return user.isAdmin();
}
Auf diese Weise muss ein Widget wissen, welche Kriterien erfüllt sein müssen, damit es von einem Benutzer aktualisiert wird, und ein Benutzer muss wissen, ob es sich um einen Administrator handelt. Dieses Design kommuniziert klar über seine Absichten und macht es einfacher, zu komplexeren Geschäftslogiken überzugehen, wenn und wann dies der Fall ist.
[Bearbeiten]
Das Problem nicht zu haben User.isAdmin()und zu benutzenPermissionManager.userHasPermission(...)
Ich dachte, ich würde meiner Antwort hinzufügen, um zu erklären, warum ich es sehr bevorzuge, eine Methode für das Benutzerobjekt aufzurufen, anstatt eine Methode für ein PermissionManager-Objekt aufzurufen, wenn ich wissen möchte, ob ein Benutzer ein Administrator ist (oder eine Administratorrolle hat).
Ich denke, es ist fair anzunehmen, dass Sie immer von der Benutzerklasse abhängen werden, wo immer Sie die Frage stellen müssen. Ist dieser Benutzer ein Administrator? Das ist eine Abhängigkeit, die man nicht loswerden kann. Wenn Sie den Benutzer jedoch an ein anderes Objekt übergeben müssen, um eine Frage zu stellen, wird eine neue Abhängigkeit von diesem Objekt über die Abhängigkeit erstellt, die Sie bereits vom Benutzer haben. Wenn die Frage häufig gestellt wird, ist dies eine Menge Stellen, an denen Sie eine zusätzliche Abhängigkeit erstellen, und es sind viele Stellen, an denen Sie möglicherweise Änderungen vornehmen müssen, wenn eine der Abhängigkeiten dies erfordert.
Vergleichen Sie dies mit dem Verschieben der Abhängigkeit in die Benutzerklasse. Jetzt haben Sie plötzlich ein System, in dem der Client-Code (Code, der die Frage stellen muss, ist dieser Benutzer ein Administrator ) nicht an die Implementierung gekoppelt ist, wie diese Frage beantwortet wird. Es steht Ihnen frei, das Berechtigungssystem vollständig zu ändern, und Sie müssen nur eine Methode in einer Klasse aktualisieren, um dies zu tun. Der gesamte Client-Code bleibt unverändert.
Wenn ich darauf bestehe, keine isAdminMethode für den Benutzer zu haben, weil ich befürchte, eine Abhängigkeit in der Benutzerklasse vom Berechtigungssubsystem zu schaffen, ist dies meiner Meinung nach vergleichbar damit, einen Dollar auszugeben, um einen Cent zu verdienen. Sicher, Sie vermeiden eine Abhängigkeit in der Benutzerklasse, müssen jedoch an jeder Stelle, an der Sie die Frage stellen müssen, eine Abhängigkeit erstellen. Kein gutes Geschäft.