Лично мне почти никогда не нужно писать абстрактные классы.
В большинстве случаев я вижу, что абстрактные классы используются (неправильно), потому что автор абстрактного класса использует шаблон «Шаблонный метод».
Проблема с «Методом шаблона» заключается в том, что он почти всегда несколько повторяется - «производный» класс знает не только о «абстрактном» методе своего базового класса, который он реализует, но и о открытых методах базового класса. , хотя в большинстве случаев это не нужно называть их.
(Чрезмерно упрощенный) пример:
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);
}
Итак, здесь автор этого класса написал общий алгоритм и намеревается, чтобы люди использовали его, «специализируя» его, предоставляя свои собственные «крючки» - в данном случае, метод «сравнения».
Таким образом, предполагаемое использование примерно так:
class NameSorter : QuickSorter
{
public bool compare(object lhs, object rhs)
{
// etc.
}
}
Проблема в том, что вы неправильно связали воедино две концепции:
- Способ сравнения двух предметов (какой предмет должен идти первым)
- Метод сортировки элементов (например, быстрая сортировка, сортировка слиянием и т. Д.)
В приведенном выше коде теоретически автор метода «сравнение» может повторно вызывать метод «Сортировка» суперкласса ... даже на практике они никогда не захотят или не будут этого делать.
Цена, которую вы платите за эту ненужную связь, состоит в том, что трудно изменить суперкласс, и в большинстве языков OO невозможно изменить его во время выполнения.
Альтернативный метод - использовать шаблон проектирования «Стратегия»:
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;
}
}
Итак, обратите внимание: все, что у нас есть, это интерфейсы и конкретные реализации этих интерфейсов. На практике вам больше ничего не нужно для создания ОО высокого уровня.
Чтобы «скрыть» тот факт, что мы реализовали «сортировку имен» с помощью класса «QuickSort» и «NameComparator», мы все равно могли бы написать метод фабрики:
ISorter CreateNameSorter()
{
return new QuickSorter(new NameComparator());
}
Каждый раз, когда у вас есть абстрактный класс, вы можете сделать это ... даже когда между базовым и производным классом существуют естественные реентерабельные отношения, обычно стоит сделать их явными.
Одна заключительная мысль: все, что мы сделали выше, это «составление» функции «NameSorting» с использованием функции «QuickSort» и функции «NameComparison» ... на функциональном языке программирования этот стиль программирования становится еще более естественным, с меньшим количеством кода.