Bonjour,
Est-ce que quelqu'un peut m'expliquer dans quel cas il faut utiliser le Design Pattern Strategy et pourquoi ?
Je ne vois vraiment pas l'intérêt…
Merci![]()
Bonjour,
Est-ce que quelqu'un peut m'expliquer dans quel cas il faut utiliser le Design Pattern Strategy et pourquoi ?
Je ne vois vraiment pas l'intérêt…
Merci![]()
On fait appel au pattern Stratégie quand un objet a besoin d'un comportement annexe qui peut être multiforme et dont il veut avoir la main sur le déclenchement et le résultat.
Si on prend le mot Stratégie au pied de la lettre, on trouve facilement des exemples avec des tactiques de jeu. Par exemple, dans Pierre-Feuilles-Ciseaux, on peut avoir différentes stratégies : toujours jouer au hasard, toujours choisir Ciseaux, choisir l'objet qui bat le coup précédent de l'adversaire, etc. L'objet O qui possède la Stratégie de jeu S1 va faire appel à elle pour déterminer quel est le coup suivant à sortir (car en vertu du principe de séparation des responsabilités, on suppose que ce n'est pas le boulot de cet objet O de le faire). De plus, la stratégie va pouvoir être remplacée par une autre S2, S3, S4... au runtime à tout moment et ainsi s'adapter au style de jeu de l'adversaire.
Merci pour la réponse
Mais ce que je n arrive pas à comprendre c'est pourquoi ne pas implémenter S1 dans une méthode de O ?
Parce que si O reçoit les données du jeu, les analyse, prend la décision de quelle stratégie adopter, et exécute toutes les étapes de chaque stratégie lui-même, on a un objet obèse qui en fait beaucoup trop. Cela viole le Single Responsibility Principle selon lequel chaque classe doit faire une seule chose et le faire bien.
Les avantages d'avoir plusieurs petites classes spécialisées plutôt qu'une seule grosse sont multiples :
- A chaque fois qu'on veut ajouter une nouvelle stratégie, on crée un nouveau fichier contenant la classe de cette stratégie plutôt que de modifier le gros fichier de l'objet O. On ne modifie pas le code actuel => moins de risque de régression ou bugs inopportuns, davantage de développeurs peuvent agir en simultané sur le code, etc.
- Une petite classe de 10 lignes est souvent plus lisible qu'une grosse de 500
- On peut plus facilement tester la validité du comportement d'une petite classe de 10 lignes qu'une grosse de 500
- Une petite classe de 10 lignes recouvrant un seul concept bien identifié est souvent plus réutilisable qu'une grosse de 500 maniant plusieurs concepts
etc.
De mon côté j'ai implémenter le design patter strategy sans m'en rendre compte, je viens de réalisé ça en lisant le post.
J'ai une classe Neuron qui prend en paramètre une classe Function, j'ai fais une petite 10e de classes dérivées de Function (TanH, Sigmoid, Gaussian, etc...) puis je passe en paramètre de mon neurone la fonction que je souhaite utiliser comme ça cela m'évite d'avoir à faire des classes dérivé de neurone, car sinon ça aurait donné un truc moche du genre : NeuronSigomoid, NeuronTanH, etc...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager