Personalmente, non ho quasi mai bisogno di scrivere lezioni astratte.
Molte volte vedo che le classi astratte vengono (mis) utilizzate, è perché l'autore della classe astratta sta usando il modello "Metodo modello".
Il problema con "Metodo modello" è che è quasi sempre rientrato in qualche modo - la classe "derivata" conosce non solo il metodo "astratto" della sua classe base che sta implementando, ma anche i metodi pubblici della classe base , anche se la maggior parte delle volte non è necessario chiamarli.
Esempio (eccessivamente semplificato):
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);
}
Quindi qui, l'autore di questa classe ha scritto un algoritmo generico e intende che le persone lo usino "specializzandolo" fornendo i propri "hook" - in questo caso, un metodo di "confronto".
Quindi l'uso previsto è qualcosa del genere:
class NameSorter : QuickSorter
{
public bool compare(object lhs, object rhs)
{
// etc.
}
}
Il problema è che hai accoppiato indebitamente due concetti:
- Un modo di confrontare due elementi (quale oggetto dovrebbe essere il primo)
- Un metodo di ordinamento degli articoli (es. Quicksort vs merge sort ecc.)
Nel codice di cui sopra, in teoria, l'autore del metodo "confrontare" può rientrante richiamare nella superclasse "Sort" metodo ... anche se in pratica non potranno mai avere bisogno di fare questo.
Il prezzo da pagare per questo accoppiamento non necessario è che è difficile cambiare la superclasse e, nella maggior parte delle lingue OO, impossibile cambiarla in fase di esecuzione.
Il metodo alternativo è invece utilizzare il modello di progettazione "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;
}
}
Quindi nota ora: tutto ciò che abbiamo sono interfacce e implementazioni concrete di quelle interfacce. In pratica, non hai davvero bisogno di nient'altro per realizzare un progetto OO di alto livello.
Per "nascondere" il fatto che abbiamo implementato "l'ordinamento dei nomi" utilizzando una classe "QuickSort" e un "NameComparator", potremmo comunque scrivere un metodo di fabbrica da qualche parte:
ISorter CreateNameSorter()
{
return new QuickSorter(new NameComparator());
}
Ogni volta che hai una classe astratta puoi farlo ... anche quando c'è una relazione di rientro naturale tra la base e la classe derivata, di solito paga renderli espliciti.
Un ultimo pensiero: tutto ciò che abbiamo fatto sopra è "comporre" una funzione "NameSorting" utilizzando una funzione "QuickSort" e una funzione "NameComparison" ... in un linguaggio di programmazione funzionale, questo stile di programmazione diventa ancora più naturale, con meno codice.