Osobiście prawie nigdy nie muszę pisać klas abstrakcyjnych.
Najczęściej widzę, że klasy abstrakcyjne są używane (źle), ponieważ autor klasy abstrakcyjnej używa wzorca „Metoda szablonu”.
Problem z „metodą szablonów” polega na tym, że prawie zawsze jest ona w pewnym stopniu ponownie uruchamiana - klasa „pochodna” wie nie tylko o „abstrakcyjnej” metodzie swojej klasy bazowej, którą implementuje, ale także o metodach publicznych klasy podstawowej , mimo że w większości przypadków nie trzeba do nich dzwonić.
(Zbyt uproszczony) przykład:
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);
}
Tak więc tutaj autor tej klasy napisał ogólny algorytm i chce, aby ludzie go używali, „specjalizując się”, zapewniając własne „zaczepy” - w tym przypadku metodę „porównania”.
Tak więc zamierzone użycie jest mniej więcej takie:
class NameSorter : QuickSorter
{
public bool compare(object lhs, object rhs)
{
// etc.
}
}
Problem polega na tym, że nadmiernie połączyłeś dwie koncepcje:
- Sposób porównywania dwóch przedmiotów (który przedmiot powinien być pierwszy)
- Metoda sortowania przedmiotów (tj. Sortowanie szybkie i scalanie itp.)
W powyższym kodzie teoretycznie autor metody „porównaj” może ponownie wywołać metodę superklasy „Sortuj” ... nawet jeśli w praktyce nigdy nie będzie tego chciał ani nie musiał.
Cena, którą płacisz za to niepotrzebne sprzężenie, polega na tym, że trudno jest zmienić nadklasę, aw większości języków OO nie można jej zmienić w czasie wykonywania.
Alternatywną metodą jest użycie zamiast tego wzorca projektowego „Strategia”:
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;
}
}
Więc zauważ teraz: wszystko, co mamy, to interfejsy i konkretne implementacje tych interfejsów. W praktyce tak naprawdę nie potrzebujesz niczego więcej, aby wykonać projekt OO na wysokim poziomie.
Aby „ukryć” fakt, że zaimplementowaliśmy „sortowanie nazw” za pomocą klasy „QuickSort” i „NameComparator”, możemy gdzieś napisać metodę fabryczną:
ISorter CreateNameSorter()
{
return new QuickSorter(new NameComparator());
}
Za każdym razem, gdy masz klasę abstrakcyjną, możesz to zrobić ... nawet jeśli istnieje naturalna relacja ponownego wejścia między klasą podstawową i pochodną, zwykle opłaca się je wyrazić.
Ostatnia myśl: wszystko, co zrobiliśmy powyżej, to „skomponowanie” funkcji „NameSorting” za pomocą funkcji „QuickSort” i funkcji „NameComparison” ... w funkcjonalnym języku programowania ten styl programowania staje się jeszcze bardziej naturalny, z mniejszym kodem.