Entscheidung zum Klassendesign

Question

Ich habe ein kleines Dilemma, bei dem Sie mir vielleicht helfen können, es zu lösen.

Ich habe heute daran gearbeitet, die Mitgliedschaft von ASP.NET zu ändern, um eine Indirektionsebene hinzuzufügen.Grundsätzlich unterstützt die Mitgliedschaft von ASP.NET Benutzer und Rollen, sodass alle Autorisierungsregeln darauf basieren, ob ein Benutzer einer Rolle angehört oder nicht.

Was ich tun muss, ist das Konzept der Funktion hinzuzufügen, bei dem ein Benutzer einer Rolle (oder Rollen) angehört und der Rolle eine oder mehrere Funktionen zugeordnet sind, sodass wir eine bestimmte Aktion basierend darauf autorisieren können, ob der Benutzer dazugehört einer Rolle zuordnen, der eine Funktion zugeordnet ist.

Allerdings hat mein Problem nichts damit zu tun, es handelt sich um ein generisches Klassendesign-Problem.

Ich möchte in meiner Basisklasse RoleProvider eine abstrakte Methode bereitstellen, um die Funktion zu erstellen (und beizubehalten), aber ich möchte es optional machen, eine Beschreibung für diese Funktion zu speichern, also muss ich meine CreateFunction-Methode mit einer Überladung erstellen, einer Die Unterschrift akzeptiert den Namen und die andere akzeptiert den Namen und die Beschreibung.

Ich kann mir folgende Szenarien vorstellen:

1. Erstellen Sie beide Signaturen mit dem abstrakten Modifikator.Dies hat das Problem, dass der Implementierer möglicherweise nicht die Best Practice beachtet, die besagt, dass eine Überladung die andere mit normalisierten Parametern aufrufen sollte und die Logik nur in der letzten sein sollte (die mit allen Parametern).Außerdem ist es nicht schön, vom Entwickler die Implementierung beider Methoden zu verlangen.

2. Erstellen Sie das erste wie virtuell und das zweite wie abstrakt.Rufen Sie den zweiten vom ersten auf und ermöglichen Sie dem Implementierer, das Verhalten zu überschreiben.Es besteht das gleiche Problem: Der Implementierer könnte beim Überschreiben „schlechte Entscheidungen“ treffen.

3. Dasselbe wie zuvor, jedoch darf der erste nicht überschrieben werden (entfernen Sie den virtuellen Modifikator).Das Problem hierbei ist, dass der Implementierer sich darüber im Klaren sein muss, dass die Methode mit einer Nullbeschreibung aufgerufen werden könnte, und dass er mit dieser Situation umgehen muss.

Ich denke, die beste Option ist die dritte ...

Wie wird dieses Szenario im Allgemeinen gehandhabt?Wenn Sie eine abstrakte Klasse entwerfen und diese überladene Methoden enthält.Das ist meiner Meinung nach nicht so ungewöhnlich...

Answer 1

Meiner Meinung nach ist die beste Kombination aus DRYness und Erzwingen des Vertrags wie folgt (im Pseudocode):

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

  public abstract constructor(name, description);
}

oder alternativ:

class Base {
  public abstract constructor(name);

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

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

In Java gibt es eine Regel, die diese Entscheidung unterstützt:„Rufen Sie niemals nicht endgültige Methoden von einem Konstruktor aus auf.“

Answer 2

Um den ersten Teil Ihres Beitrags zu beantworten, schauen Sie sich AzMan (Authorization Manager) an, der übrigens in Windows integriert ist.Es bietet die Möglichkeit, Vorgänge zu spezifizieren, die in Rollen zusammengefasst oder direkt Benutzern zugewiesen werden können.

Kasse

Um den zweiten Teil Ihrer Frage zu beantworten, würde ich keine Abstract-Klasse verwenden.Stellen Sie stattdessen einfach die Funktionalität im Konstruktor bereit und fertig.Es scheint, dass Sie das angegebene Verhalten wünschen, aber nicht, dass es sich ändert.Warum Nachkommen zwingen, die Implementierung bereitzustellen?