c# - sirve - que es una clase abstracta en programacion
No estoy seguro de cuándo usar una propiedad abstracta y cuando no (5)
Los miembros abstractos son simplemente miembros virtuales que debe anular. Lo utiliza para algo que debe implementarse, pero no se puede implementar en la clase base.
Si desea crear una propiedad virtual y desea que se anule en la clase que hereda su clase, la convertiría en una propiedad abstracta.
Si, por ejemplo, tienes una clase de animal, su capacidad para respirar no sería posible de determinar solo por la información de que es un animal, pero es algo que es bastante crucial:
public abstract class Animal {
public abstract bool CanBreathe { get; }
}
Para un pez y un perro, la implementación sería diferente:
public class Dog : Animal {
public override bool CanBreathe { get { return !IsUnderWater; } }
}
public class Fish : Animal {
public override bool CanBreathe { get { return IsUnderWater; } }
}
No estoy seguro de qué se ve mejor o cuándo realmente lo uso en clases y propiedades abstractas, o cuándo usar propiedades no abstractas. Trataré de hacer un simple ejemplo. Digamos que tengo esto:
abstract class Human
{
public GenderType Gender { get; set; }
public string Name { get; set; }
public Date Born { get; set; }
public bool IsNerd { get; set; }
abstract public void Speak();
abstract public void Sleep();
abstract public void AnoyingPeopleOnStackOverflow();
//... so on
}
class Peter : Human
{
//Peter is special, he got a second name
//But thats all, everything else is the same as like on other humans
public string SecondName { get; set; }
//...override abstract stuff
}
¿Está bien? Según entendí, no tengo que usar una propiedad abstracta si no quiero anularla. Y en esta situación estaría bien, solo los métodos como Speak
, Sleep
y demás deberían ser abstractos.
Ahora, si esto está bien, ¿cuándo o debería usar una propiedad abstracta?
Sé lo que quiero que hagan, no me importa cómo lo hacen: interfaz.
Sé lo que quiero que hagan, no me importa cómo lo hacen, pero tengo ideas firmes sobre cómo harán (o al menos la mayoría) otros elementos: clase abstracta.
Sé lo que quiero que hagan, y cómo la mayoría de ellos lo hará: clase concreta con miembros virtuales.
Puede tener otros casos como, por ejemplo, una clase abstracta sin miembros abstractos (no puede tener una instancia de uno, sino qué funcionalidad ofrece, ofrece completamente), pero son más raros y normalmente surgen porque una jerarquía particular se ofrece limpia y descaradamente a un problema determinado.
(Por cierto, no pensaría en un Peter como un tipo de Humano, sino en cada peter como un ejemplo de humano que se llama Peter. No es realmente justo elegir el código de ejemplo de esta manera, pero cuando uno volver a pensar en este tipo de problema es más pertinente de lo normal).
Se usará una propiedad abstracta en la que desee que la clase siempre exponga la propiedad, pero donde no se pueda precisar la implementación de esa propiedad, dejándola / forzando a la clase heredera a hacerlo.
Aquí hay un ejemplo, donde la clase abstracta se llama Shape
y expone una propiedad abstracta del Area
. No puede implementar la propiedad Area
en la clase base, ya que la fórmula del área cambiará para cada tipo de forma. Todas las formas tienen un área (de algún tipo), por lo que todas las formas deben exponer la propiedad.
Su implementación en sí misma se ve bien. Estaba tratando de pensar en un ejemplo sensato de una propiedad abstracta para un Human
, pero no podía pensar en nada razonable.
Use una propiedad abstracta cuando no tenga una implementación predeterminada y cuando las clases derivadas deban implementarla.
Use una propiedad virtual cuando tenga una implementación en la clase base pero quiera permitir la anulación.
Utilice la palabra clave de anulación para anular un miembro. Marque el miembro como sealed override
si no se debe anular de nuevo.
No marque la propiedad como abstract
o virtual
si no desea que se anule.
Use la new
palabra clave para ocultar un miembro no abstracto y no virtual (esto rara vez es una buena idea).
Cómo: Definir propiedades abstractas
Encuentro que las propiedades abstractas a menudo ocurren en un diseño que implica que tendrán una lógica específica de tipo y / o efectos secundarios. Básicamente estás diciendo, "aquí hay un punto de datos que todas las subclases deben tener, pero no sé cómo implementarlo". Sin embargo , las propiedades que contienen una gran cantidad de efectos secundarios de lógica y / o causa pueden no ser deseables. Esta es una consideración importante, aunque no existe una forma correcta, correcta o incorrecta de hacerlo.
Ver:
- En caso de que las propiedades tengan efectos secundarios
- CA1024: use propiedades donde sea apropiado
Personalmente, encuentro que uso métodos abstractos con frecuencia, pero las propiedades abstractas rara vez.
Utilice el resumen cuando todas las subclases tengan que implementar el método / propiedad. Si no es necesario que todas y cada una de las sub-clases lo implementen, entonces no lo use.
En cuanto a su ejemplo, si SecondName
no es necesario para cada persona, entonces no es necesario crear una propiedad abstracta en la clase base. Si, por otro lado, cada persona necesita un segundo nombre, entonces conviértalo en una propiedad abstracta.
Ejemplo de uso correcto de una propiedad abstracta:
public class Car
{
public abstract string Manufacturer { get; }
}
public class Odyssey : Car
{
public override string Manufacturer
{
get
{
return "Honda";
}
}
}
public class Camry : Car
{
public override string Manufacturer
{
get
{
return "Toyota";
}
}
}
Hacer que Maker
abstracto es correcto porque cada automóvil tiene un fabricante y debe poder decirle al usuario quién es ese fabricante.