Supponiamo di avere la seguente classe:
class Foo
{
public:
void func()
{
_func1();
_func2();
}
private:
virtual void _func1();
virtual void _func2();
};
Questa classe, da un lato, specifica l'interfaccia (metodo foo ) e, dall'altro, definisce l'implementazione (prima chiamiamo _func1 , poi _func2 ). Quindi viola il principio di responsabilità unica?
No. Non di per sé.
Se decidi SRP come »facendo una cosa sola«, avresti ragione, ma non lo è, cosa significa SRP .
Dovresti leggere SRP più come: »trattare con un livello di astrazione«
Ciò che è "un livello di astrazione" è lasciato al lettore come un esercizio.
In effetti, lo fa - in una certa misura. Ecco perché esiste un altro modello per ottenere lo stesso efficacemente, ma senza violare l'SRP: il modello strategia , utilizzato in una "classe di contesto" come questa:
class Context
{
private:
IStrategy *_strategy;
public:
void func()
{
_strategy->_func1();
_strategy->_func2();
}
};
Tuttavia, come sempre quando si prendono decisioni di progettazione, questo è un compromesso: l'uso del modello di strategia produce un codice un po 'più generico, e le funzioni virtuali ora devono essere fatte public invece di protected , quindi allenta l'incapsulamento in una certa misura. Dovrai scambiare "YAGNI" con "SRP" qui.
Per le classi piccole o i metodi di template, il "pattern method template" è del tutto sufficiente, per quelli più grandi, la "strategia" potrebbe essere la scelta migliore. E a volte, l'uso di nessun modello è la soluzione migliore di tutti .
Leggi altre domande sui tag single-responsibility template-method