Decisión de diseño de clase

Question

Tengo un pequeño dilema que tal vez puedas ayudarme a resolver.

He estado trabajando hoy para modificar la membresía de ASP.NET para agregar un nivel de direccionamiento indirecto.Básicamente, la membresía de ASP.NET admite usuarios y roles, dejando que todas las reglas de autorización se basen en si un usuario pertenece a un rol o no.

Lo que necesito hacer es agregar el concepto de Función, donde un usuario pertenecerá a un rol (o roles) y el rol tendrá una o más funciones asociadas, permitiéndonos autorizar una acción específica en función de si el usuario pertenece. a un rol que tiene una función asignada.

Dicho esto, mi problema no tiene nada que ver con eso, es una cuestión de diseño de clase genérica.

Quiero proporcionar un método abstracto en mi clase base RoleProvider para crear la función (y conservarla), pero quiero que sea opcional guardar una descripción para esa función, por lo que necesito crear mi método CreateFunction con una sobrecarga, una firma aceptando el nombre, y la otra aceptando el nombre y la descripción.

Puedo pensar en los siguientes escenarios:

1. Crea ambas firmas con el modificador abstracto.Esto tiene el problema de que el implementador puede no respetar la mejor práctica que dice que una sobrecarga debe llamar a la otra con los parámetros normalizados, y la lógica solo debe estar en la final (la que tiene todos los parámetros).Además, no es bueno exigir que el desarrollador implemente ambos métodos.

2. Crea el primero como virtual y el segundo como abstracto.Llame al segundo desde el primero, permita que el implementador anule el comportamiento.Tiene el mismo problema, el implementador podría tomar "malas decisiones" al anularlo.

3. Igual que antes, pero no permita que se anule el primero (elimine el modificador virtual).El problema aquí es que el implementador debe ser consciente de que el método podría llamarse con una descripción nula y debe manejar esa situación.

Creo que la mejor opción es la tercera...

¿Cómo se maneja este escenario en general?Cuando diseñas una clase abstracta y contiene métodos sobrecargados.No es tan raro creo...

Answer 1

Siento que la mejor combinación de DRYness y forzar el contrato es la siguiente (en pseudocódigo):

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

  public abstract constructor(name, description);
}

o alternativamente:

class Base {
  public abstract constructor(name);

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

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

Hay una regla en Java que respalda esta decisión:"Nunca llames a métodos no finales desde un constructor".

Answer 2

Para responder a la primera parte de su publicación, consulte AzMan (Administrador de autorización), que, dicho sea de paso, está integrado en Windows.Tiene la capacidad de especificar operaciones que pueden recombinarse en roles o asignarse directamente a los usuarios.

Verificar

Para responder a la segunda parte de tu pregunta, no usaría una clase abstracta.En su lugar, simplemente proporcione la funcionalidad en el constructor y termine con ello.Parece que desea el comportamiento especificado y no desea que cambie.¿Por qué obligar a los descendientes a proporcionar la implementación?