Personalmente, casi nunca tengo la necesidad de escribir clases abstractas.
La mayoría de las veces veo que se usan (mal) las clases abstractas, es porque el autor de la clase abstracta está usando el patrón "Método de plantilla".
El problema con el "Método de plantilla" es que casi siempre es algo reentrante: la clase "derivada" conoce no solo el método "abstracto" de su clase base que está implementando, sino también los métodos públicos de la clase base. , aunque la mayoría de las veces no es necesario llamarlos.
Ejemplo (demasiado simplificado):
abstract class QuickSorter
{
public void Sort(object[] items)
{
// implementation code that somewhere along the way calls:
bool less = compare(x,y);
// ... more implementation code
}
abstract bool compare(object lhs, object rhs);
}
Así que aquí, el autor de esta clase ha escrito un algoritmo genérico y pretende que las personas lo usen "especializándolo" proporcionando sus propios "ganchos", en este caso, un método de "comparación".
Entonces, el uso previsto es algo como esto:
class NameSorter : QuickSorter
{
public bool compare(object lhs, object rhs)
{
// etc.
}
}
El problema con esto es que ha unido indebidamente dos conceptos:
- Una forma de comparar dos elementos (qué elemento debe ir primero)
- Un método para ordenar elementos (es decir, clasificación rápida frente a combinación, etc.)
En el código anterior, teóricamente, el autor del método "comparar" puede volver a llamar al método "Ordenar" de la superclase ... aunque en la práctica nunca querrán o necesitarán hacer esto.
El precio que paga por este acoplamiento innecesario es que es difícil cambiar la superclase, y en la mayoría de los lenguajes OO, es imposible cambiarlo en tiempo de ejecución.
El método alternativo es utilizar el patrón de diseño "Estrategia" en su lugar:
interface IComparator
{
bool compare(object lhs, object rhs);
}
class QuickSorter
{
private readonly IComparator comparator;
public QuickSorter(IComparator comparator)
{
this.comparator = comparator;
}
public void Sort(object[] items)
{
// usual code but call comparator.Compare();
}
}
class NameComparator : IComparator
{
bool compare(object lhs, object rhs)
{
// same code as before;
}
}
Así que observe ahora: todo lo que tenemos son interfaces e implementaciones concretas de esas interfaces. En la práctica, realmente no necesitas nada más para hacer un diseño OO de alto nivel.
Para "ocultar" el hecho de que hemos implementado la "clasificación de nombres" mediante el uso de una clase "QuickSort" y un "NameComparator", aún podríamos escribir un método de fábrica en alguna parte:
ISorter CreateNameSorter()
{
return new QuickSorter(new NameComparator());
}
Cada vez que tenga una clase abstracta puede hacer esto ... incluso cuando haya una relación natural entrante entre la clase base y la clase derivada, generalmente vale la pena hacerlas explícitas.
Una última reflexión: todo lo que hemos hecho anteriormente es "componer" una función de "Clasificación de nombres" utilizando una función de "Clasificación rápida" y una función de "Comparación de nombres" ... en un lenguaje de programación funcional, este estilo de programación se vuelve aún más natural, con menos código