Les modèles de conception sont des solutions de niveau de conception pour les problèmes récurrents que nous, ingénieurs logiciels, rencontrons souvent. Ce n’est pas du code – je répète, CODE CODE. C’est comme une description sur la façon de s’attaquer à ces problèmes et à concevoir une solution.
L’utilisation de ces modèles est considérée comme une bonne pratique, car la conception de la solution est assez éprouvée, ce qui se traduit par une plus grande lisibilité du code final., Les modèles de conception sont assez souvent créés et utilisés par les langages de POO, comme Java, dans lesquels la plupart des exemples à partir d’ici seront écrits.
Types de modèles de conception
Il y a environ 26 modèles actuellement découverts (je pense à peine que je les ferai tous…).
Ces 26 peuvent être classés en 3 types:
1. Creational: ces modèles sont conçus pour l’instanciation de classe. Ils peuvent être des modèles de création de classe ou des modèles de création d’objet.
2. Structural: ces motifs sont conçus en fonction de la structure et de la composition d’une classe., L’objectif principal de la plupart de ces modèles est d’augmenter la fonctionnalité de la ou des classes impliquées, sans changer une grande partie de sa composition.
3. Comportemental: ces modèles sont conçus en fonction de la façon dont une classe communique avec les autres.
dans cet article, nous allons passer en revue un modèle de conception de base pour chaque type classé.
Type 1: Creational – The Singleton Design Pattern
Le Singleton Design Pattern est un modèle de création, dont l’objectif est de créer une seule instance d’une classe et de fournir un seul point d’accès global à cet objet., Un exemple couramment utilisé d’une telle classe en Java est Calendar, où vous ne pouvez pas créer d’instance de cette classe. Il utilise également sa propre méthodegetInstance()pour obtenir l’objet à utiliser.
Une Classe utilisant le modèle de conception singleton comprendra,
- une variable statique privée, contenant la seule instance de la classe.
- Un constructeur privé, il ne peut donc pas être instancié ailleurs.
- Une méthode statique publique, pour retourner l’instance unique de la classe.,
Il existe de nombreuses implémentations différentes de singleton conception. Aujourd’hui, je vais passer en revue les implémentations de;
1. Instanciation désireuse
2. Instanciation paresseuse
3. Instanciation Thread-safe
Eager Beaver
public class EagerSingleton {// create an instance of the class.private static EagerSingleton instance = new EagerSingleton();// private constructor, so it cannot be instantiated outside this class.private EagerSingleton() { }// get the only instance of the object created.public static EagerSingleton getInstance() {return instance;}}ce type d’instanciation se produit pendant le chargement de la classe, car l’instanciation de l’instance de variable se produit en dehors de toute méthode. Cela pose un gros inconvénient si cette classe n’est pas utilisé par l’application cliente. Le plan d’urgence, si cette classe n’est pas utilisée, est L’instanciation paresseuse.,
Lazy Days
Il n’y a pas beaucoup de différence par rapport à l’implémentation ci-dessus. Les principales différences sont que la variable statique est d’abord déclarée nulle, et est instancié dans le getInstance() méthode si – et seulement si – la variable d’instance reste nulle au moment de la vérification.
cela résout un problème, mais un autre existe toujours. Que se passe-t-il si deux clients différents accèdent à la classe Singleton en même temps, jusqu’à la milliseconde?, Eh bien, ils vérifieront si l’instance est nulle en même temps, et la trouveront vraie, et créeront donc deux instances de la classe pour chaque demande des deux clients. Pour résoudre ce problème, l’instanciation sécurisée des threads doit être implémentée.
(Thread) la sécurité est la clé
En Java, le mot-clé synchronized est utilisé sur des méthodes ou des objets pour implémenter la sécurité des threads, de sorte qu’un seul thread accède à une ressource particulière à la fois. L’instanciation de classe est placée dans un bloc synchronisé de sorte que la méthode ne soit accessible que par un seul client à un moment donné.,
La surcharge de la méthode synchronisée est élevé, et réduit les performances de l’ensemble de l’opération.
par exemple, si la variable d’instance a déjà été instanciée, alors chaque fois qu’un client accède à la méthode getInstance(), la méthode synchronized est exécutée et les performances diminuent. Cela se produit simplement afin de vérifier si la valeur des variables instance est null. S’il trouve que c’est le cas, il quitte la méthode.
pour réduire cette surcharge, un double verrouillage est utilisé., La vérification est également utilisée avant la méthode synchronized, Et si la valeur est nulle seule, la méthode synchronized s’exécute-t-elle.
passons maintenant à la classification suivante.
de Type 2: Structurel, Le Décorateur
je vais vous donner un petit scénario pour donner un meilleur contexte pour pourquoi et où vous devez utiliser le Pattern Décorateur.
dites que vous possédez un café, et comme tout débutant, vous commencez avec seulement deux types de café nature, le mélange maison et le rôti foncé., Dans votre système de facturation, il y avait une classe pour les différents mélanges de café, qui hérite de la classe résumé des boissons. Les gens commencent réellement à venir et ont votre merveilleux (bien qu’amer?) café. Ensuite, il y a les newbs de café qui, à Dieu ne plaise, veulent du sucre ou du lait. Une telle parodie pour le café!! ??
Maintenant, vous devez avoir ces deux add-ons ainsi, à la fois dans le menu et malheureusement sur le système de facturation. À l’Origine, votre informaticien fera une sous-classe pour les deux cafés, l’un comprenant le sucre, l’autre le lait., Puis, comme les clients ont toujours raison, on dit ces mots redoutables:
« puis-je obtenir un café au lait, avec du sucre, s’il vous plait?”
???
votre système de facturation vous rit à nouveau au visage. Eh bien, à la planche à dessin….
l’informaticien ajoute ensuite du café au lait avec du sucre comme une autre sous-classe à chaque classe de café parent. Le reste du mois est une navigation fluide, les gens font la queue pour prendre votre café, vous gagnez de l’argent. ??
mais attendez, il y a plus!
le monde est à nouveau contre vous., Un concurrent s’ouvre de l’autre côté de la rue, avec non seulement 4 types de café, mais plus de 10 add-ons aussi! ?
vous achetez tous ceux-ci et plus encore, pour vendre un meilleur café vous-même, et rappelez-vous alors que vous avez oublié de mettre à jour ce système de facturation dratted. Vous ne pouvez probablement pas faire le nombre infini de sous-classes pour toutes les combinaisons de tous les add-ons, avec les nouveaux mélanges de café aussi. Sans parler de la taille du système final.??
Il est temps d’investir réellement dans un système de facturation approprié., Vous trouvez un nouveau personnel informatique, qui sait réellement ce qu’ils font et ils disent;
« pourquoi, ce sera tellement plus facile et plus petit s’il utilisait le motif du décorateur.”
Ce que sur terre est qu’?
le modèle de conception de décorateur tombe dans la catégorie structurelle, qui traite de la structure réelle d’une classe, que ce soit par héritage, composition ou les deux. Le but de cette conception est de modifier la fonctionnalité d’un objet lors de l’exécution. C’est l’un des nombreux autres modèles de conception qui utilisent des classes abstraites et des interfaces avec la composition pour obtenir le résultat souhaité.,
donnons une chance aux mathématiques (frissonner?) pour mettre tout cela en perspective;
prenez 4 mélanges de café et 10 add-ons. Si nous nous en tenons à la génération de sous-classes pour chaque combinaison différente de tous les add-ons pour un type de café. C’est;
(10-1)2 = 92 = 81 sous-classes
nous soustrayons 1 des 10, car vous ne pouvez pas combiner un add-on avec un autre du même type, sugar with sugar semble stupide. Et c’est pour un seul mélange de café. Multipliez ce 81 par 4 et vous obtenez un énorme 324 sous-classes différentes!, Parlez de tout ce codage
Mais avec le motif décorateur, il ne faudra que 16 classes dans ce scénario. Vous voulez parier?
Si nous traçons notre scénario selon le diagramme de classe ci-dessus, nous avons 4 classes pour les 4 mélanges de café, de 10 pour chaque add-on et 1 pour le résumé de la composante et 1 de plus pour le résumé de décorateur. Voir! 16!, Maintenant, remettez ces 100$.?? (jk, mais il ne sera pas refusé s’il est donné just juste en disant)
comme vous pouvez le voir ci-dessus, tout comme les mélanges de café concrets sont des sous-classes de la classe abstraite de boisson, la classe abstraite AddOn hérite également de ses méthodes. Les modules complémentaires, qui sont ses sous-classes, héritent à leur tour de toutes les nouvelles méthodes pour ajouter des fonctionnalités à l’objet de base en cas de besoin.
passons au codage, pour voir ce modèle en cours d’utilisation.,
d’abord pour faire la classe de boisson abstraite, que tous les différents mélanges de café hériteront de:
puis pour ajouter les deux classes de mélange de café concret.
La classe addon abstract hérite également de la classe Beverage abstract (plus à ce sujet ci-dessous).
et maintenant les implémentations concrètes de cette classe abstraite:
comme vous pouvez le voir ci-dessus, nous pouvons passer n’importe quelle sous-classe de Beverage à n’importe quelle sous-classe D’AddOn, et obtenir le coût supplémentaire ainsi que la description mise à jour. Et, puisque la classe AddOn est essentiellement de type Beverage, nous pouvons passer un AddOn dans un autre AddOn., De cette façon, nous pouvons ajouter n’importe quel nombre d’add-ons à un mélange de café spécifique.
maintenant, écrivez du code pour tester cela.
Le résultat final est le suivant:
Ça marche!!! Nous avons pu ajouter plus d’un add-on à un mélange de café et mettre à jour avec succès son coût final et sa description, sans avoir besoin de créer une infinité de sous-classes pour chaque combinaison d’add-on pour tous les mélanges de café.
enfin, à la dernière catégorie.,
Type 3: comportemental – le modèle de conception de commande
Un modèle de conception comportementale se concentre sur la façon dont les classes et les objets communiquent entre eux. L’objectif principal du modèle de commande est d’inculquer un degré plus élevé de couplage lâche entre les parties impliquées (lire: classes).
Uhhhh… Qu’est-ce que c’est?
le couplage est la façon dont deux classes (ou plus) qui interagissent l’une avec l’autre interagissent. Le scénario idéal lorsque ces classes interagissent est qu’elles ne dépendent pas fortement les unes des autres. C’est le couplage lâche., Ainsi, une meilleure définition du couplage lâche serait, les classes qui sont interconnectées, faisant le moins usage les unes des autres.
le besoin de ce modèle est apparu lorsque les demandes devaient être envoyées sans savoir consciemment ce que vous demandez ou qui est le destinataire.
dans ce modèle, la classe d’appel est découplée de la classe qui effectue réellement une action. L’invocateur classe n’a remboursables méthode execute, qui exécute la commande nécessaire, lorsque le client le demande.
prenons un exemple réel de base, en commandant un repas dans un restaurant chic., Au fur et à mesure que le flux va, vous donnez votre commande (Commande) au serveur (invoker), qui la remet ensuite au chef(récepteur), afin que vous puissiez obtenir de la nourriture. Cela peut sembler simple… mais un peu meh au code.
L’idée est assez simple, mais le codage va autour du nez.,
le flux de fonctionnement du côté technique est, vous faites une commande concrète, qui implémente l’interface de commande, demandant au récepteur de terminer une action, et d’envoyer la commande à L’invocateur est la personne qui sait quand cette commande. Le chef est le seul à savoir quoi faire lorsqu’on lui donne la commande/l’ordre spécifique., Ainsi, lorsque la méthode execute de l’invocateur est exécutée, elle provoque à son tour l’exécution de la méthode execute des objets de commande sur le récepteur, complétant ainsi les actions nécessaires.,
Ce que nous devons mettre en œuvre;
- Une interface de Commande
- Un Ordre de classe qui implémente l’interface de Commande
- Une classe Serveur (invocateur)
- Un Chef de classe (récepteur)
Donc, le codage va comme ceci:
le Chef, le récepteur
la Commande, l’interface
public interface Command {public abstract void execute();}l’Ordre, le béton de la commande
Serveur, de l’invocateur
public class Waiter {private Order order;public Waiter(Order ord) {this.order = ord;}public void execute() {this.order.execute();}}Vous, le client
Comme vous pouvez le voir ci-dessus, le Client fait une Commande et le Récepteur comme le Chef., La commande est envoyée au serveur, qui saura quand exécuter la commande (c’est-à-dire quand donner au chef l’ordre de cuisiner). Lorsque l’invocateur est exécuté, la méthode execute des ordres est exécutée sur le récepteur (c’est-à-dire que le chef reçoit la commande de cuire des pâtes ? ou cuire le gâteau?).,
résumé rapide
dans cet article, nous avons examiné:
- qu’est-ce qu’un modèle de conception est vraiment,
- Les différents types de modèles de conception et
- Un modèle de conception de base ou commun pour chaque type
j’espère que cela a été utile.
trouvez le repo de code pour le post, ici.