metodos - C#, implementa métodos abstractos estáticos

params comments c#

Question

Recientemente me encontré con un problema donde parece que necesito un método de "resumen estático". Sé por qué es imposible, pero ¿cómo puedo evitar esta limitación?

Por ejemplo, tengo una clase abstracta que tiene una cadena de descripción. Como esta cadena es común para todas las instancias, se marca como estática, pero deseo solicitar que todas las clases derivadas de esta clase proporcionen su propia propiedad de Descripción, por lo que la marqué como abstracta:

abstract class AbstractBase
{
    ...
    public static abstract string Description{get;}
    ...
}

No compilará, por supuesto. Pensé en usar interfaces, pero las interfaces pueden no contener firmas de métodos estáticos.

¿Debo hacerlo simplemente no estático, y siempre obtengo una instancia para obtener esa clase de información específica?

¿Algunas ideas?

Answer 1

La combinación de estático y abstracto es algo sin sentido, sí. La idea detrás de la estática es que no es necesario presentar una instancia de la clase para usar el miembro en cuestión; sin embargo, con el resumen, uno espera que una instancia sea de una clase derivada que proporciona una implementación concreta.

Puedo ver por qué querría este tipo de combinación, pero el hecho es que el único efecto sería denegar el uso de implementación de ''este'' o cualquier miembro no estático. Es decir, la clase padre dictaría una restricción en la implementación de la clase derivada, aunque no haya una diferencia subyacente entre llamar a un miembro abstracto o ''resumen estático'' (ya que ambos necesitarían una instancia concreta para descubrir qué implementación usar)

Answer 2

No es estático si debe invocarse en una instancia.

Si no lo está llamando en una instancia, entonces no hay polimorfismo en juego (es decir, ChildA.Description está completamente relacionado con ChildB.Description en lo que respecta al lenguaje).

Answer 3

No puedes

El lugar para hacer esto es con Atributos.

P.ej

[Name("FooClass")]
class Foo
{
}

Answer 4

Podría hacer que el método base "abstracto" arroje una Exception , por lo que un desarrollador será "advertido" si intenta invocar este método en una clase secundaria sin anularlo.

El inconveniente es que uno podría extender la clase y no usar este método. Luego consulte otras respuestas proporcionadas.

Answer 5

Si es estático, solo hay una instancia de la variable, no veo cómo la herencia tendría sentido si pudiéramos hacer lo que queremos lograr con variables estáticas en las clases derivadas. Personalmente, creo que vas a intentar evitar una instancia var.

¿Por qué no solo de la manera clásica?

abstract class AbstractBase
{
    protected string _Description = "I am boring abstract default value";
}

class Foo : AbstractBase {

     public Foo() {
       _Description = "I am foo!";
     }
}

Answer 6

Si no le importa aplazar las implementaciones para implementar de manera sensata la propiedad Descripción, puede simplemente hacer

public abstract string ClassDescription {get; } 
// ClassDescription is more intention-revealing than Description

Y la implementación de clases haría algo como esto:

static string classDescription="My Description for this class";
override string  ClassDescription { get { return classDescription; } }

Luego, se requiere que sus clases sigan el contrato de tener una descripción, pero usted les deja hacerlo con sensatez. No hay forma de especificar una implementación de forma orientada a objetos (excepto a través de hacks crueles y frágiles).

Sin embargo, en mi opinión esta Descripción es metadata de clase, por lo que preferiría usar el mecanismo de atributo como otros lo han descrito. Si está particularmente preocupado por los múltiples usos de la reflexión, cree un objeto que refleje sobre el atributo que le preocupa y almacene un diccionario entre el Tipo y la Descripción. Eso minimizará la reflexión (aparte de la inspección de tipo de tiempo de ejecución, que no es del todo mala). El diccionario se puede almacenar como miembro de cualquier clase que normalmente necesite esta información o, si los clientes de todo el dominio lo requieren, a través de un objeto singleton o de contexto.