Ich habe die folgende Klasse:
%Vor%Wird das eine "Gottesklasse"?
Ich bin unsicher, ob ich diese Klasse aufteilen sollte. Das Problem dabei ist, dass die Methoden dieser Klasse von ihrer Domäne verwendet werden, um zu bestimmen, ob bestimmte UI-Elemente auf Webseiten angezeigt werden sollen. Daher gibt es in der Klasse kein Verhalten.
Ich nehme an, ich könnte die permission-related-Methoden in eine Permission-Klasse stellen und diese Methoden statisch machen (zB :: userIsGroupAdministrator (...), :: userIsMemberOfGroup (...) :: userHasGroupPermission (...) , :: userHasContentPermission (...))
Irgendwelche Vorschläge, wie diese Klasse besser sein könnte?
Wenn Sie bereits laufenden Code haben, refaktorieren Sie ihn in kleinen Stücken. Wenn nicht, würde ich Folgendes betrachten:
%Vor%Der Rest gehört wirklich in eine Serviceklasse:
%pr_e%
Es ist schwer von Methodennamen allein zu unterscheiden. Eine Heuristik, die ich verwende, um eine Klasse aufzulösen, besteht darin, die Zustandsvariablen zu betrachten. Gibt es Staatsteile, die dazu neigen, zusammen benutzt zu werden? Können sie in eine separate Klasse aufgeteilt werden?
Es hilft Ihnen, wenn Sie beschreiben könnten, wie sich Ihr User -Objekt verhält, mit wem es alles interagiert, was es ist, Umgebung usw.
Ich nehme an, dass ich die berechtigungsbezogenen Methoden in eine Berechtigungsklasse schreiben könnte [...]
Ja, Sie können sich das richtlinienbasierte Design ansehen.
Ich würde auch vorschlagen, dass Sie den fixed-state von User , d. h. E-Mail / Name usw. herausnehmen und in eine separate Klasse einfügen.
Wie schwierig ist es jetzt, neue Funktionen hinzuzufügen oder bestehende Funktionen in Ihrer Anwendung beizubehalten? Wenn Sie in dieser Hinsicht keine Probleme haben, dann sind Sie wahrscheinlich OK, die Dinge so zu behalten, wie sie sind (zumindest für eine Weile).
Ja, Ihre Benutzerklasse hat einige sich überschneidende Verantwortlichkeiten, die möglicherweise in eine rollenbasierte Zugriffskontrolle umgestaltet werden können System.
Die Quintessenz ist: Bist du wirklich wird es brauchen ?
Sie scheinen separate ACL- und Role-Objekte vom User-Objekt zu benötigen.
Ссылка
Sie können auch sehen, wie es in ZF funktioniert .
Aus Gründen der Lesbarkeit können Sie statt __get() und __set() verwenden :
Es ist nicht so schlimm, aber ich denke, Ihre Berechtigungen Mechaniker könnten Factoring verwenden. Das ist ein Fall, der eindeutig nach Aggregation und nicht nach Vererbung verlangt. Wenn die Möglichkeit besteht, dass nicht-triviale Kontaktinformationen mit dem Benutzer verknüpft werden, möchten Sie möglicherweise auch die E-Mail-Adresse herausfiltern, möglicherweise in eine Identität, in die bei Bedarf weitere Kontaktinformationen geladen werden können.
Im Allgemeinen kann ich empfehlen, dass Sie Ihren Benutzer als einen zentralen Punkt zum Aggregieren und Komponieren von Funktionsuntereinheiten betrachten - ein Ansatz, der in der Spielentwicklung unter der Rubrik "Entitätssystem" den Buzzword-Status erreicht. p>
Lassen Sie diese ... sie finden IMO:
%Vor%Schlage vor, dass Sie diese durch Funktionen zum Abrufen / Festlegen von Namen ersetzen, die eine Instanz von TUserName behandeln:
%Vor%TUserName würde haben:
%Vor%Schlagen Sie vor, dass Sie diese mit Get / Set Admin-Funktionen ersetzen, die eine Instanz von TUserGroup behandeln:
%Vor%TUserGroup hätte:
%Vor%Schlagen Sie vor, dass Sie diese mit Get / Set Permission-Funktionen ersetzen, die eine Instanz von TUserPermissions behandeln:
%Vor%TUserPermissions hätte:
%Vor%Solange die Methoden in der Klasse Instanzdaten zurückgeben oder nur den internen Status ändern, ist nichts an der Klasse falsch.
Aber für z.B. Wenn die Methode canLogIn () nach einem externen Dienst (Repository, Mitgliedschaftsdienst usw.) sucht, gibt es ein Problem der Einfachheit und Testbarkeit. Wenn dies der Fall ist, müssen Sie eine Serviceklasse haben und diese Methoden verwenden. Wie
%Vor%Ich würde in Erwägung ziehen, eine Berechtigungsklasse zu erstellen und ein Mitglied der Benutzerklasse zu machen.
Ich würde zumindest die Funktion setCanLogIn($canLogIn) entfernen. Dies sollte wirklich intern in der Klasse basierend darauf bestimmt werden, ob der Benutzer die korrekten Anmeldeinformationen angegeben und authentifiziert wurde.
Abhängig davon, wie groß dieses Projekt ist oder ob es Teil eines Frameworks ist, wird bestimmt, ob mehr Abstraktion benötigt wird.
Es sieht einigermaßen plausibel aus. Ich kenne die Anwendung natürlich nicht. Ich denke, es könnte sinnvoll sein, eine Permissions-Klasse herauszufiltern.
Idealerweise sollten Sie darüber nachdenken, was es bedeutet, eine Berechtigungsklasse zu haben - was weiß sie, was sind ihre tatsächlichen Aktionen? Da "Berechtigungen" im Plural sind, könnten Sie sich auch fragen, ob Sie wirklich eine Sammlung von einzelnen Permission-Objekten haben möchten, aber ob diese effektiv Accessoren für einen einfachen Booleschen Wert sind, der möglicherweise übertrieben ist.
Tags und Links php design-patterns oop