Décision de conception de classe

Question

J'ai un petit dilemme que peut-être vous pouvez m'aider à trier.

J'ai travaillé aujourd'hui en modifiant l'adhésion d'ASP.NET pour ajouter un niveau d'indirection. Fondamentalement, l'appartenance à ASP.NET prend en charge les utilisateurs et les rôles, laissant toutes les règles d'autorisation basées sur le fait qu'un utilisateur appartient à un rôle ou non. Ce que je dois faire est d'ajouter le concept de la fonction, où un utilisateur appartiendra à un rôle (ou rôles) et le rôle aura une ou plusieurs fonctions qui leur sont associées, ce qui nous permet d'autoriser une action spécifique basée sur si l'utilisateur appartient à un rôle auquel une fonction est affectée. Cela dit, mon problème n'a rien à voir avec ça, c'est un problème de conception de classe générique. Je veux fournir une méthode abstraite dans ma classe RoleProvider de base pour créer la fonction (et la persister), mais je veux la rendre facultative pour enregistrer une description pour cette fonction, donc j'ai besoin de créer ma méthode CreateFunction avec une surcharge, une signature acceptant le nom, et l'autre acceptant le nom et la description.

Je peux penser aux scénarios suivants:

1. Créer deux signatures avec le modificateur abstrait. Cela pose le problème que l'implémenteur peut ne pas respecter la meilleure pratique qui dit qu'une surcharge devrait appeler l'autre avec les paramètres normalisés, et la logique ne devrait être que dans le dernier (celui avec tous les paramètres). De plus, il n'est pas agréable d'exiger que les deux méthodes soient implémentées par le développeur.

2. Créez le premier comme le virtuel et le second comme le résumé. Appelez le second à partir du premier, autorisez l'implémenteur à remplacer le comportement. Il a le même problème, l'exécutant pourrait prendre de "mauvaises décisions" en le dépassant.

3. Comme précédemment, mais ne permet pas de remplacer le premier (supprimez le modificateur virtuel). Le problème ici est que l'implémenteur doit être conscient que la méthode peut être appelée avec une description nulle et doit gérer cette situation.

Je pense que la meilleure option est le troisième ...

Comment ce scénario géré en général? Lorsque vous concevez une classe abstraite et qu'elle contient des méthodes surchargées. Il est pas rare que je pense ...

Answer 1

Je me sens la meilleure combinaison de force et le degré de séchage contrat est la suivante (en pseudocode):

class Base { 
    public final constructor(name) { 
    constructor(name, null) 
    end 

    public abstract constructor(name, description); 
} 

ou bien:

class Base { 
    public abstract constructor(name); 

    public final constructor(name, description) { 
    constructor(name) 
    this.set_description(description) 
    } 

    private final set_description(description) { 
    ... 
    } 
} 

Il existe une règle dans Java qui prend en charge cette décision: "n'appelez jamais de méthodes non finales à partir d'un constructeur".

Answer 2

Pour répondre à la première partie de votre message, consultez AzMan (Authorization Manager), qui, incidemment, est intégré à Windows. Il a la capacité de spécifier des opérations qui peuvent être recombinées dans des rôles ou assignées directement aux utilisateurs.

Check out

Pour répondre à la deuxième partie de votre question, je ne voudrais pas utiliser une classe abstraite. Au lieu de cela, fournissez simplement la fonctionnalité dans le constructeur et faites-le avec. Il appeasr vous voulez le comportement spécifié, et vous ne voulez pas qu'il change. Pourquoi forcer les descendants à fournir la mise en œuvre.