Décision de conception de classe

Question

J'ai un petit dilemme que vous pourrez peut-être m'aider à résoudre.

J'ai travaillé aujourd'hui sur la modification de l'adhésion à ASP.NET pour ajouter un niveau d'indirection.Fondamentalement, l'adhésion d'ASP.NET prend en charge les utilisateurs et les rôles, laissant toutes les règles d'autorisation basées sur l'appartenance ou non d'un utilisateur à un rôle.

Ce que je dois faire, c'est ajouter le concept de fonction, où un utilisateur appartiendra à un ou plusieurs rôles et le rôle sera associé à une ou plusieurs fonctions, nous permettant d'autoriser une action spécifique en fonction de l'appartenance de l'utilisateur. à un rôle auquel est assignée une fonction.

Cela dit, mon problème n'a rien à voir avec cela, c'est un problème de conception de classe générique.

Je souhaite fournir une méthode abstraite dans ma classe de base RoleProvider pour créer la fonction (et la conserver), mais je souhaite la rendre facultative pour enregistrer une description de cette fonction. Je dois donc 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éez les deux signatures avec le modificateur abstrait.Cela pose le problème que l'implémenteur peut ne pas respecter la meilleure pratique selon laquelle une surcharge doit appeler l'autre avec les paramètres normalisés, et la logique ne doit être que dans la version finale (celle avec tous les paramètres).De plus, ce 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 virtuel et le second comme abstrait.Appelez le deuxième à partir du premier, autorisez l'implémenteur à remplacer le comportement.Il a le même problème, l'implémenteur pourrait prendre de "mauvaises décisions" en l'ignorant.

3. Comme avant, mais ne permettez pas que le premier soit remplacé (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 la troisième...

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

Answer 1

Je pense que la meilleure combinaison de DRYness et de forcer le 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 en 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 est d'ailleurs intégré à Windows.Il a la capacité de spécifier des opérations qui peuvent être recombinées en rôles ou attribuées directement aux utilisateurs.

Vérifier

Pour répondre à la deuxième partie de votre question, je n'utiliserais pas de classe Abstract.Au lieu de cela, fournissez simplement la fonctionnalité dans le constructeur et terminez-la.Il semble que vous souhaitiez le comportement spécifié et que vous ne vouliez pas qu'il change.Pourquoi forcer les descendants à assurer la mise en œuvre.