J'essaie de comprendre le modèle de stratégie et je me demande: la classe de contexte est-elle indispensable ou puis-je la laisser sans compromettre l'objectif du modèle?
J'avais l'impression que j'avais besoin d'une sorte de commutateur pour lire différents types de fichiers, mais je ne voulais pas simplement pirater quelque chose et traiter plus tard du refactoring (bien que, bien sûr, il arrive toujours que le code puisse être refactoré, mais l'idée était: essayez pour être le plus intelligent possible dans la conception au préalable ...):
Image prise à partir de wikimedia
Le client peut-il déléguer directement à l'interface de stratégie ou y a-t-il quelque chose que j'ai manqué de comprendre à propos de la classe de contexte?
interface Reader {
// read information from file and fill data list field of Client
readFile();
}
class ExcelReader implements Reader{ /* */ }
class PdfReader implements Reader{ /* */}
class Client{
// strategic choice
Reader r;
// data list field
List<Data> data;
// Client Constructor
public Client(){
if(<file ends in .xls>)
r = new ExcelReader();
else
r = new PdfReader();
r.readFile();
}
}
Ainsi, la classe de contexte ci-dessus est manquante. Le code adhère-t-il au modèle de stratégie?
la source
Réponses:
Dans votre exemple, l'appel de code
readFile
fait partie du constructeur Client. Cette méthode est le "contexte" que vous recherchez . Le modèle de stratégie n'a pas besoin d'une "classe de contexte" littéralement, et dans la première version de votre code, l'objet de stratégie (le "Reader" dans votre cas) peut résider uniquement dans une variable locale. Surtout quand il n'y a qu'une seule "méthode stratégique" ("readFile") à appeler.Cependant, si votre base de code évolue d'une version à l'autre, il est peu probable que de plus en plus de méthodes "stratégiques" soient appelées, et la décision de la stratégie à appliquer et de l'exécution des "méthodes stratégiques" se produira à différents moments. et à différents endroits de votre code. Vous commencez donc à les refactoriser pour garder la logique au même endroit. Cela mènera directement à une implémentation similaire au schéma de votre question.
la source
Certainement. Les modèles ne sont que des lignes directrices. Vous devrez toujours les adapter et les appliquer correctement pour le problème en question. Personnellement, j'autorise rarement la stratégie à être définie lors de l'exécution; le plus souvent, il est spécifié lors de la construction ou filé dans une usine.
Bien qu'il puisse également être soutenu que
setStrategy
c'est privé et mon injection utilise simplement le modèle comme indiqué.la source