'
Bienvenue dans le premier article de la série «Design Patterns Exposed». Dans cette série, nous allons découvrir chaque modèle de conception à partir de zéro.
Connaître simplement un langage de programmation et ses constructions ne fera pas de vous un meilleur programmeur ou développeur. Cela nécessite une connaissance des modèles de conception pour créer un logiciel qui fonctionnera aujourd'hui et également à l'avenir.
De nombreux développeurs ont déjà rencontré les problèmes de conception auxquels vous êtes confrontés actuellement ou auxquels vous devrez faire face à l'avenir. Ils ont spécifié une manière standard de traiter ce problème. Ainsi, en utilisant des modèles de conception, vous bénéficiez de l’avantage d’utiliser des techniques éprouvées.
Chaque modèle de conception sert à résoudre un type particulier de situation, il peut y avoir des situations où plusieurs modèles de conception peuvent être utilisés.
La plupart des programmeurs essaient simplement de résoudre le problème auquel ils sont confrontés sans se soucier des modèles de conception, du code redondant ou même du couplage étroit. Mais les bons programmeurs commencent différemment. Ils réfléchissent aux exigences d'aujourd'hui, aux exigences futures, à la maintenance du code et à la réutilisation du code.
Les bons programmeurs ne sont pas pressés de commencer à coder une fois qu'ils ont satisfait aux exigences. Ils s'assoient et réfléchissent au problème de savoir si leur conception fonctionnera. Si oui, si cela fonctionnera après 6 mois, quand les exigences changeront.
Les bons programmeurs prennent leur stylo et leur papier et commencent à concevoir leurs classes et leurs relations entre les classes. Ils essaient d'obtenir un couplage lâche et une cohésion élevée dans leur conception, tout en faisant tout cela, ils ont des principes orientés objet dans leur esprit. Ils n'entrent pas immédiatement dans le code de bas niveau. Pour concevoir des logiciels flexibles et réutilisables, vous devez suivre cette approche, sinon vous vous retrouverez toujours à modifier le code que vous aviez écrit précédemment.
Il n'y a qu'une seule chose qui est constante dans l'industrie du logiciel et c'est Changement. Les exigences continueront certainement de changer. Alors, comment concevons-nous le logiciel que votre code peut facilement adapter aux exigences futures? Pour cela, vous devez commencer tôt et le concevoir de manière à ce que les exigences futures ne cassent pas votre code précédent.
Comment puis je faire ça?
Eh bien, cela peut être fait en suivant les principes de conception et les modèles de conception basés sur ces principes.
Maintenant, plongeons dans le codage et commençons à devenir un meilleur programmeur. Dans cet article, nous allons découvrir l'un des modèles les plus importants - Modèle de stratégie .
Quand je dis le plus important, cela reflète le problème commun qui est résolu par Strategy Pattern.
Qu'est-ce que le modèle de stratégie?
Voici la définition tirée directement du livre 'Gang of Four': 'Le modèle de stratégie est utilisé pour créer une famille d'algorithmes interchangeables à partir de laquelle le processus requis est choisi au moment de l'exécution».
Au cas où tu espas en mesure de comprendre, ne vous inquiétez pas, nous allons vous l'expliquer dans unplus simplefaçonpour toi decomprendre.
Commençons par comprendre le problème, puis nous verrons comment le modèle de stratégie peut le résoudre.
Dans le diagramme UML ci-dessus, nous avons la classe abstraite Animal et deux classes concrètes, Dog et Bird, s'étendant de la super classe Animal.
Définissons donc une classe abstraite Animal et deux classes concrètes, Dog et Bird.
Que pensez-vous de la conception ci-dessus? Il y a une grosse erreur dans notre conception.
Tous les animaux ne peuvent pas voler, comme dans le cas ci-dessus, un chien ne peut pas voler. Mais il a toujours un comportement de «mouche».
Nous avons fait une erreur en écrivant la méthode abstraite fly () dans la classe Animal. Cette conception obligera chaque sous-classe Dog, Bird, Penguin, Crocodile, Goose, etc. à implémenter la méthode fly ().
Nous aurions dû comprendre que voler est une capacité que tous les animaux n'auront pas. En fournissant la méthode fly () dans la classe Animal abstract, nous avons défini la capacité de vol dans toutes les sous-classes, ce qui n'est pas correct pour toutes les sous-classes d'animaux.
Vous pourriez vous demander quel est le problème lors de l’implémentation de la méthode fly dans les sous-classes. Bien que vous puissiez implémenter la méthode fly () dans les sous-classes Animal non-volant pour simplement afficher 'Je ne peux pas voler'. Mais le problème est que vous donnez toujours le comportement de mouche à des animaux non volants. Ce n'est pas correct.
Qu'est-ce que ça fait d'appeler dog.fly () ou crocodile.fly ().
Donc, maintenant nous avons compris que notre conception n'est pas correcte et nous devrions supprimer la méthode fly () de la sous-classe Animal.
Quelle est l'autre façon de concevoir nos classes de manière à ce que notre conception n'impose pas à toutes les sous-classes d'animaux d'avoir un comportement de mouche.
Une solution qui vient immédiatement à l'esprit est que nous pouvons créer une interface de vol avec une méthode de vol et que seuls les animaux capables de voler implémenteront cette interface de vol. De cette façon, nous n'appliquerons pas toutes les sous-classes d'animaux pour définir un comportement de mouche. Alors codons cette approche de conception.
Maintenant, notre classe Animal ressemblera au code ci-dessous après avoir supprimé la méthode fly de la classe Animal.
Définissons maintenant l'interface Flying
Maintenant, la classe de chien sera modifiéecommele code ci-dessous et il n'a pas besoin d'avoir un comportement de vol.
Voyons quelques-unes de nos sous-classes d'animaux qui auront un comportement de vol.
Nous avons résolu notre problème précédent, mais nous avons eu un nouveau problème, celui de la «duplication de code».
Dites, nous allons avoir 100 sous-classes différentes d'animaux volants. Nous devons dupliquer le code pour le comportement de vol car l'interface de vol ne peut fournir aucune implémentation pour le comportement de vol, et plus tard si nous voulons changer l'implémentation de la méthode fly () dans n'importe quelle sous-classe, nous devrons ouvrir cette classe et changer le code, ce qui est mauvais. Il nous manque quelque chose de grand et, autrement dit, nous ne pouvons pas changer le comportement de vol d'une classe au moment de l'exécution.
Mais ne vous inquiétez pas, Strategy Pattern est là pour vous sortir de ce problème.
Refactorisons donc notre code pour utiliser le modèle de stratégie.
L'interface de vol restera la même telle qu'elle est. Maintenant, plutôt que chaque sous-classe de vol implémentant l'interface de vol elle-même, nous allons définir des classes concrètes distinctes qui implémenteront différents comportements de vol. Voyons comment procéder.
Alors, comment tout cela fonctionne, voyons le TestClass
En utilisant le modèle de stratégie, nous sommes maintenant en mesure de modifier le comportement de vol de n'importe quel animal au moment de l'exécution et cela sans appliquer aucune sous-classe pour spécifier le comportement de vol lui-même.
Quand utiliser Strategy Pattern?
Lorsque vous souhaitez pouvoir modifier dynamiquement le comportement au moment de l'exécution.
Pour être sûr de bien comprendre le modèle de stratégie, prenons un autre exemple.
Dans la catégorie d'employés ci-dessus, nous fixons la rémunération de l'employé en fonction de sa désignation. Si un employé est un «stagiaire», nous ajoutons une prime de 10% au salaire de base pour calculer le salaire réel.
Si un employé est un «développeur Web», nous ajoutons une prime de 20% dans le salaire de base pour calculer le salaire réel et le processus similaire suit pour les autres types d'employés. Bien que notre algorithme de calcul du salaire réel soit très simple pour le rendre plus facile à comprendre, il comprend la plupart du temps de nombreuses comparaisons et calculs.
Alors, quel est le problème avec le code de la classe des employés?
Eh bien, le code de calcul du salaire (getPay ()) est statique. Supposons que je veuille changer le bonus pour «stagiaire» de 10% à 14%. Je devrai ouvrir le code de la classe Employé et le modifier.
Et un autre problème est que je ne peux pas changer l'algorithme de paie d'un employé au moment de l'exécution. Alors, comment faire ça? Le modèle de stratégie est spécifiquement utilisé pour gérer ce type de problème.
Refactorisons le code pour utiliser le modèle de stratégie.
Je vais définir plusieurs algorithmes pour calculer la rémunération. Ensuite, je pourrai utiliser l'un de ces algorithmes pour calculer la rémunération au moment de l'exécution.
Voyons maintenant comment la classe d'employé va changer.
convertir la chaîne en format de date en java
Remarque: J'ai supprimé la logique de calcul de la paie de la classe Employé et créé une méthode PayAlgorithm () définie par laquelle je définirai l'algorithme PayAlgorithm que je souhaite utiliser pour le calcul de la paie.
Cela me donnera la flexibilité de calculer la paie en spécifiant dynamiquement n'importe quel PayAlgorithm au moment de l'exécution. Notez également que plus tard, si je dois changer la logique de calcul de la paie, je peux créer un nouvel algorithme de paye et l'utiliser pour calculer la paie. Je n'ai pas besoin de modifier le code précédent, n'est-ce pas génial?
Alors voyons cela fonctionner.
J'espère que vous avez très bien compris le modèle de stratégie. La meilleure façon d'apprendre quelque chose est de pratiquer.
Si vous avez des questions relatives au modèle de stratégie ou à tout autre modèle, laissez vos questions ci-dessous.
Surveillez le prochain article, où nous découvrirons l'un des modèles de conception les plus populaires, Factory Pattern.
Jusque-là, vous pouvez télécharger le code pour jouer avec et vous assurer de cimenter le modèle de stratégie dans votre tête.
Vous avez une question pour nous? Mentionnez-les dans la section commentaires et nous vous recontacterons.
Articles Similaires: