Introduction détaillée à 23 modèles de conception Java courants-javaDidacticiel-php.cn

Cet article vous apporte des connaissances pertinentes sur java. Il présente principalement plusieurs modèles de conception courants qui sont un ensemble d'expériences de conception de code qui ont été utilisées à plusieurs reprises. Le but est de réutiliser le code et de le rendre plus facile pour les autres. pour comprendre et garantit la fiabilité du code, j'espère qu'il sera utile à tout le monde.

Introduction détaillée à 23 modèles de conception Java courants

Étude recommandée : "Tutoriel Java"

1. Aperçu des modèles de conception :

1. Qu'est-ce qu'un modèle de conception :

Un modèle de conception est un ensemble d'expériences de conception de code qui ont été utilisées à plusieurs reprises. Le but est de réutiliser le code, de le rendre plus facile à comprendre par les autres et d'assurer la fiabilité du code. Les modèles de conception sont gagnant-gagnant pour nous-mêmes, pour les personnes et pour les systèmes. Cela fait de l'écriture de code une véritable ingénierie. C'est la pierre angulaire du génie logiciel, tout comme les briques et les pierres d'un bâtiment. L'utilisation raisonnable des modèles de conception dans les projets peut parfaitement résoudre de nombreux problèmes. Chaque modèle a des principes correspondants dans la réalité pour y correspondre. Chaque modèle décrit un problème qui revient sans cesse autour de nous et le cœur de la solution. largement utilisé. De manière générale, les modèles de conception sont divisés en trois grandes catégories :

Modèles créatifs : 5 au total : modèle de méthode d'usine, modèle d'usine abstrait, modèle singleton, modèle de constructeur, modèle de prototype

Modèles structurels : 7 au total Types : adaptateur mode, mode décorateur, mode proxy, mode pont, mode apparence, mode combinaison, mode poids mouche

Mode comportemental : 11 types au total : mode stratégie, mode méthode modèle, mode observateur, mode chaîne de responsabilité, accès mode Médiateur, mode intermédiaire , mode itérateur, mode commande, mode état, mode mémo, mode interprète

En fait, il en existe deux types : le mode concurrent et le mode pool de threads. Utilisez une image pour décrire le tout :

2. . Les six principes des modèles de conception :

(1) Principe d'ouverture et de fermeture :

Le principe d'ouverture et de fermeture fait référence au fait d'être ouvert pour l'expansion et fermé pour la modification. Lors de l'extension du programme, le code original ne peut pas être modifié. Pour obtenir cet effet, nous devons utiliser des interfaces ou des classes abstraites

(2) Principe d'inversion de dépendance :

Dépendance Le principe d'inversion est la base de l'ouverture et de la fermeture. principe, qui fait référence à une programmation d'interface qui repose sur l'abstraction plutôt que sur le concret. (3) Principe de substitution de Liskov :

Le principe de substitution de Liskov est l'héritage et la pierre angulaire de la réutilisation uniquement lorsque la sous-classe peut remplacer la classe de base et les fonctions de. le système n'est pas affecté, la classe de base peut être réutilisée et la sous-classe peut également ajouter de nouveaux comportements à la classe de base. Ainsi, le principe de substitution de Liskov signifie que partout où une classe de base peut apparaître, une sous-classe doit apparaître.

Le principe de substitution de Liskov est un complément au « principe d'ouverture et de fermeture ». L'étape clé pour réaliser le « principe d'ouverture et de fermeture » est l'abstraction, et la relation d'héritage entre la classe de base et la sous-classe est la mise en œuvre concrète de l'abstraction. , donc le principe de substitution de Liskov Il s'agit d'une spécification d'étapes spécifiques pour réaliser l'abstraction.

(4) Principe de ségrégation des interfaces :

Il est préférable d'utiliser plusieurs interfaces isolées plutôt que d'utiliser une seule interface, ce qui réduit le couplage et la dépendance entre les interfaces, ce qui facilite la mise à niveau et la maintenance

( 5) Principe de Demeter :

Le principe de Demeter, également connu comme le principe le moins connu, signifie qu'une classe doit minimiser les interactions avec d'autres entités, rendant les modules fonctionnels du système relativement indépendants et réduisant les relations de couplage. L'intention initiale de ce principe est de réduire le couplage des classes. Bien que la communication avec les classes indirectes puisse être évitée, la communication doit se faire par un « intermédiaire ». L'utilisation excessive du principe Demeter produira un grand nombre d'intermédiaires et le passage des classes mènera à une plus grande complexité du système, donc lorsque vous utilisez la loi de Dimit, vous devez peser à plusieurs reprises les compromis pour obtenir à la fois une structure claire, une cohésion élevée et un faible couplage.

(6) Principe de réutilisation composite :

Essayez d'utiliser la combinaison/agrégation au lieu de l'héritage.

2. 23 modèles de conception en Java :

Ensuite, nous présenterons en détail les concepts, les scénarios d'application, etc. des 23 modèles de conception en Java, et les analyserons en fonction de leurs caractéristiques et des principes des modèles de conception

1. Créer un modèle de méthode Type-factory :

Le modèle de méthode Factory est divisé en trois types :

(1) Modèle d'usine simple :

Créez une classe d'usine et définissez une interface pour créer des classes de produits qui implémentent la même interface. Regardez d'abord le diagramme de relation :

(2) Modèle de méthode d'usine :

Le modèle de méthode d'usine est une amélioration du modèle d'usine simple. Le défaut de l'usine simple est qu'elle n'est pas conforme au modèle d'usine simple. "Principe d'ouverture et de fermeture". Chaque fois qu'une nouvelle classe de produit nécessite une modification de la classe d'usine, ce qui n'est pas propice à l'expansion et à la maintenance du système. La méthode factory fait abstraction de l'usine et définit une interface pour créer des objets. Chaque fois que vous ajoutez un nouveau produit, il vous suffit d'ajouter le produit et la classe d'usine d'implémentation spécifique correspondante. La classe d'usine spécifique détermine le produit à instancier et retarde la création et l'instanciation de l'objet dans la sous-classe, de sorte que le produit soit instancié. la conception de l'usine est conforme au « principe d'ouverture et de fermeture », il n'est pas nécessaire de modifier le code original lors de l'expansion. Le diagramme de relation UML est le suivant :

(3) Modèle de méthode d'usine statique :

Le modèle d'usine statique rend les méthodes du modèle de méthode d'usine statiques. Il n'est pas nécessaire de créer une instance, il suffit d'appeler. directement.

Article détaillé sur le modèle de méthode d'usine : Type de création de modèle de conception Java : Explication détaillée du modèle d'usine (usine simple + méthode d'usine + usine abstraite)

2. Type de création - modèle d'usine abstrait :

Le modèle d'usine abstrait. Le modèle d'usine est principalement utilisé pour créer des familles d'objets associés. Lorsqu'une famille de produits doit être conçue pour fonctionner ensemble, le modèle d'usine abstrait peut garantir que le client utilise toujours uniquement des objets de la même famille de produits et, en isolant la génération de classes spécifiques, le client n'a pas besoin de spécifier explicitement les classes spécifiques ; génération. Toutes les usines concrètes implémentent l'interface publique définie dans l'usine abstraite, il vous suffit donc de modifier l'instance de l'usine concrète pour modifier dans une certaine mesure le comportement de l'ensemble du système logiciel.

Mais l'inconvénient de ce modèle est qu'il est plus gênant d'ajouter de nouveaux comportements. Si vous devez ajouter un nouvel objet famille de produits, vous devez changer l'interface et toutes ses sous-classes, ce qui causera inévitablement beaucoup de problèmes.

Le diagramme de structure UML est le suivant :

Détails du modèle d'usine abstrait : Type de création du modèle de conception Java : Explication détaillée du modèle d'usine (usine simple + méthode d'usine + usine abstraite)

3. type - modèle de constructeur :

Le modèle de construction décompose les étapes de création de produits complexes en différentes méthodes, rendant le processus de création plus clair et contrôlant ainsi plus précisément le processus de génération d'objets complexes en isolant la construction et l'utilisation d'objets complexes ; , la création de produits Séparé du produit lui-même, le même processus de construction peut créer différents objets ; et chaque constructeur en béton est indépendant les uns des autres, il est donc facile de remplacer le constructeur en béton ou d'ajouter un nouveau constructeur en béton, et les utilisateurs utilisent différents Les constructeurs concrets peuvent alors obtenir différents objets produits. Le diagramme de structure UML est le suivant :

Détails du modèle de générateur : Type de création du modèle de conception Java : Modèle de générateur

4. Type de création - modèle singleton :

Le modèle singleton peut garantir que une certaine classe A n'a qu'une seule instance. La classe s'instancie et fournit un point d'accès public pour cette instance à l'ensemble du système. À l'exception de ce point d'accès public, l'instance n'est pas accessible par d'autres moyens. Les avantages du mode singleton sont les suivants :

Il n'y a qu'un seul objet d'instance partagé dans le système. Il n'est pas nécessaire de créer et de détruire fréquemment des objets, ce qui économise les ressources du système et améliore les performances du système.
Peut contrôler strictement comment et quand. les clients accèdent à l’objet singleton.

Il existe plusieurs façons d'écrire le modèle singleton, il en existe trois types principaux : le singleton de style homme paresseux, le singleton de style homme affamé et le singleton de style enregistrement.

Détails du modèle singleton : Type de création du modèle de conception Java : modèle singleton

5. Modèle de type prototype de création :

Le modèle prototype est également utilisé pour la création d'objets. prototype, le Il effectue une copie-clone, produisant un nouvel objet similaire à l'objet source. Le diagramme de classes UML est le suivant :

En Java, le cœur du modèle de prototype est la classe prototype Prototype. La classe Prototype doit remplir les deux conditions suivantes :

Implémentez l'interface Cloneable :
Remplacez la méthode clone() dans la classe Object pour renvoyer une copie de l'objet ;

La méthode clone() dans la classe Object est par défaut une copie superficielle. copie de l'objet, vous devez alors personnaliser votre propre logique de copie dans la méthode clone().

Copie superficielle : après avoir copié un objet, les variables du type de données de base seront recréées et le type de référence pointe toujours vers l'adresse mémoire pointée par l'objet d'origine.
Copie approfondie : après la copie d'un objet, les types de données de base et les types de référence sont recréés.

Utiliser le mode prototype pour créer des objets simplifie non seulement les étapes de création d'objets, mais offre également de bien meilleures performances que la création d'objets à l'aide de la nouvelle méthode, car la méthode clone() de la classe Object est une méthode locale qui exploite directement le flux binaire en mémoire, en particulier lors de la copie d'objets volumineux, la différence de performances est très évidente

Détails du modèle de prototype : Type de création du modèle de conception Java : Modèle de prototype

Nous avons introduit 5 types de modèles de création ci-dessus, et nous allons maintenant commencer à introduire 7 modes de type de structures : mode adaptateur, mode décoration, mode proxy, mode apparence, mode pont, mode combinaison, mode poids mouche. Le mode adaptateur de l'objet est à l'origine de différents modes, comme le montre la figure ci-dessous :

6, mode adaptateur structuré :

le mode adaptateur est principalement utilisé pour convertir une classe ou une interface au format de l'objet. l'espoir du client, afin que les classes incompatibles d'origine puissent fonctionner ensemble pour découpler la classe cible et la classe adaptateur, il est également conforme au « principe d'ouverture et de fermeture », et de nouvelles classes d'adaptateur peuvent être ajoutées sans modifier le code d'origine ; est encapsulé dans La classe adaptateur est transparente pour la classe client et améliore la réutilisation de l'adaptateur. Cependant, l'inconvénient est que le processus de mise en œuvre de remplacement de l'adaptateur est relativement compliqué.

Par conséquent, le modèle d'adaptateur est plus adapté aux scénarios suivants :

(1) Le système doit utiliser des classes existantes et les interfaces de ces classes ne sont pas conformes aux interfaces du système.
(2) Lors de l'utilisation de composants tiers, la définition de l'interface du composant est différente de votre propre définition. Vous ne souhaitez pas modifier votre propre interface, mais vous devez utiliser les fonctions de l'interface du composant tiers.

Ce qui suit est un exemple très frappant qui illustre ce qu'est le modèle d'adaptateur :

Il existe trois implémentations principales du modèle d'adaptateur : le modèle d'adaptateur de classe, le modèle d'adaptateur d'objet et le modèle d'adaptateur d'interface. Les scénarios d'utilisation des trois sont les suivants :

Modèle d'adaptateur de classe : lorsque vous souhaitez convertir une classe en une classe qui répond à une autre nouvelle interface, vous pouvez utiliser le modèle d'adaptateur de classe pour créer une nouvelle classe et hériter de la classe d'origine. , et implémentez Juste une nouvelle interface.
Modèle d'adaptateur d'objet : lorsque vous souhaitez convertir un objet en un objet qui satisfait à une autre nouvelle interface, vous pouvez créer une classe Wrapper et conserver une instance de la classe d'origine dans la méthode de la classe Wrapper, appelez simplement la méthode d'instance. .
Modèle d'adaptateur d'interface : lorsque vous ne souhaitez pas implémenter toutes les méthodes dans une interface, vous pouvez créer une classe abstraite Wrapper pour implémenter toutes les méthodes. Lorsque nous écrivons d'autres classes, nous pouvons simplement hériter de la classe abstraite.

Détails du modèle d'adaptateur : Type structurel des modèles de conception Java : Modèle d'adaptateur

7. Type structurel - Modèle de décorateur :

Le modèle de décorateur peut ajouter dynamiquement des responsabilités supplémentaires à l'objet pour étendre la fonctionnalité de sélection. différents décorateurs au moment de l'exécution pour obtenir différents comportements ; c'est plus flexible que l'utilisation de l'héritage. En organisant et en combinant différentes classes de décoration, vous pouvez créer de nombreux comportements différents et obtenir des objets plus puissants, il est conforme au "principe d'ouverture et de fermeture" , le décoré ; La classe et la classe décorée changent indépendamment. Les utilisateurs peuvent ajouter de nouvelles classes décorées et des classes décorées selon leurs besoins, puis les combiner lors de leur utilisation. Le code d'origine n'a pas besoin d'être modifié. Le schéma de structure UML du modèle décorateur est le suivant :

Mais le modèle décorateur présente également des inconvénients. Premièrement, il générera beaucoup de petits objets, ce qui augmente la complexité du système. Deuxièmement, il est plus difficile. pour déboguer. Pour les objets à décorations multiples, la recherche d'erreurs pendant le débogage peut nécessiter un dépannage étape par étape, ce qui est fastidieux.

Détails du modèle de décorateur : type structurel de modèle de conception Java : modèle de décorateur

8. Modèle de proxy structurel :

La motivation de conception du modèle de proxy est d'accéder à l'objet réel via l'objet proxy en établissant une classe proxy d'objet, l'objet proxy contrôle la référence de l'objet d'origine, réalisant ainsi le. fonctionnement de l'objet réel. En mode proxy, l'objet proxy joue principalement le rôle d'un intermédiaire, utilisé pour coordonner et connecter l'appelant (c'est-à-dire le client) et l'appelé (c'est-à-dire l'objet cible), ce qui réduit dans une certaine mesure le couplage du système et également Target objet protégé. Mais l'inconvénient est qu'un objet proxy est ajouté entre l'appelant et l'appelé, ce qui peut ralentir le traitement des requêtes. Le diagramme de structure UML est le suivant :

Détails du modèle de proxy : Type structurel du modèle de conception Java : modèle de proxy

9 Type structurel - modèle de pont :

Le modèle de pont sépare et découple l'abstrait. partie du système de la partie implémentation, afin qu'ils puissent changer indépendamment. Afin d'atteindre l'objectif de permettre à la partie abstraite et à la partie implémentation de changer indépendamment, le mode pont utilise une relation de combinaison au lieu d'une relation d'héritage. La partie abstraite a un objet d'interface de la partie implémentation, de sorte que les fonctions de la partie abstraite soient modifiées indépendamment. une partie d'implémentation spécifique peut être appelée via cet objet d'interface. En d'autres termes, le pont en mode pont est une relation à sens unique, et seule la partie abstraite peut utiliser les objets de la partie implémentation, mais pas l'inverse.

Le mode pont est conforme au « principe d'ouverture et de fermeture », ce qui améliore l'évolutivité du système. Vous pouvez arbitrairement étendre l'une des deux dimensions changeantes sans modifier le système d'origine et les détails de mise en œuvre sont opaques pour les clients et peuvent se cacher. détails de mise en œuvre. Cependant, étant donné que la relation d'agrégation est établie au niveau de la couche d'abstraction, les développeurs doivent programmer l'abstraction, ce qui augmente la difficulté de compréhension et de conception du système. Le schéma de structure UML du mode pont est le suivant :

Tout comme en Java, lorsque nous utilisons JDBC pour nous connecter à la base de données, nous basculons entre différentes bases de données. Il n'est fondamentalement pas nécessaire de déplacer trop de code. La raison est que le mode pont est utilisé, JDBC fournit une interface unifiée, chaque base de données fournit sa propre implémentation, puis la classe pont crée un pilote pour se connecter à la base de données. Lorsque vous utilisez une certaine base de données, il vous suffit de changer. Le schéma structurel de JDBC est le suivant :

Dans JDBC, le rôle d'implémentation (Implementor) du mode pont est l'interface Driver, le rôle d'implémentation concrète (Concrete Implementor) correspond à MysqlDriver, OracleDriver et MariadbDriver, et le Le rôle d'abstraction étendue (Refined Abstraction) ) correspond à DriverManager et n'a pas de rôle d'abstraction (Abstraction) en tant que classe parent du rôle d'abstraction étendue.情 Mode pont Détails : Type structurel de Java Mode de conception : Mode pont

10, Mode structurel forme-apparence :

Le mode apparence fournit une interface unifiée au client pour accéder à un groupe d'interfaces dans le sous-système. L'utilisation du mode apparence présente les avantages suivants :

(1) Plus facile à utiliser : il rend le sous-système plus facile à utiliser. Le client n'a plus besoin de comprendre l'implémentation interne du sous-système, ni d'interagir avec les modules internes. de nombreux sous-systèmes. Il vous suffit d'interagir avec la classe d'apparence ;

(2) Couplage lâche : découplez le client du sous-système, ce qui facilite l'extension et la maintenance des modules au sein du sous-système.

(3) Meilleure division des niveaux d'accès : grâce à une utilisation raisonnable de Facade, les niveaux d'accès peuvent être mieux divisés. Certaines méthodes sont externes au système et certaines méthodes sont utilisées en interne au sein du système. Concentrez les fonctions qui doivent être exposées à l'extérieur dans la façade, ce qui est non seulement pratique à utiliser pour les clients, mais cache également bien les détails internes.

Mais si le modèle d'apparence impose trop de restrictions sur les classes de sous-systèmes, cela réduira la variabilité et la flexibilité. Par conséquent, le modèle d'apparence est adapté pour fournir une interface simple pour des sous-systèmes complexes, améliorer la convivialité du système et introduire le modèle d'apparence. Le sous-système est découplé du client pour améliorer l'indépendance et la portabilité du sous-système.

Le diagramme de structure UML du modèle d'apparence est le suivant :

Détails du modèle d'apparence : Type structurel du modèle de conception Java : Modèle d'apparence

11. Mode de combinaison structurelle :

Le mode de combinaison combine de manière récursive des objets feuille et des objets conteneurs pour former une structure arborescente représentant la structure hiérarchique « partie-tout », permettant aux utilisateurs d'utiliser facilement des objets uniques et des objets combinés. , la capacité de traiter les objets composites comme des objets feuilles sans distinction, permet aux programmes utilisateur d'être découplés de la structure interne des éléments complexes.

La chose la plus critique à propos du mode combinaison est que les objets feuille et les objets combinaison implémentent la même classe de construction abstraite. Il peut représenter à la fois les objets feuille et les objets conteneur. .La raison pour laquelle les nœuds feuilles et les nœuds objets peuvent être traités de manière cohérente. Le diagramme de structure UML du modèle de combinaison est le suivant :

Détails du modèle de combinaison : Type structurel du modèle de conception Java : modèle de combinaison

12. Type structurel-modèle de poids mouche :

Le modèle de poids mouche est. Prise en charge efficace par la technologie de partage Réutilisation fine des objets avec de petits changements d'état Lorsqu'il existe plusieurs objets identiques dans le système, une seule copie est partagée. Il n'est pas nécessaire d'instancier un objet pour chacun, ce qui réduit considérablement le nombre d'objets. dans le système, économisant ainsi des ressources.

Le cœur du modèle flyweight est la classe d'usine flyweight. La classe d'usine flyweight maintient un pool de stockage d'objets lorsque le client a besoin d'un objet, il l'obtient d'abord à partir du pool flyweight. , il renvoie directement, s'il n'existe pas dans le pool flyweight, créez une nouvelle instance d'objet flyweight et renvoyez-la à l'utilisateur, et enregistrez le nouvel objet dans le pool flyweight, qui a la signification d'un singleton.

Les classes Factory utilisent généralement des types de collection pour enregistrer des objets, tels que HashMap, Hashtable, Vector, etc. En Java, les pools de connexions à la base de données, les pools de threads, etc. sont tous des applications qui utilisent le modèle Flyweight.

Le diagramme de structure UML du modèle de poids mouche est le suivant :

' ' ' s ' s ' s t t t out out out out out out out out Out out out from à in Java through . . Les constantes de chaîne de Java sont stockées dans le pool de constantes de chaîne et la JVM garantira qu'il n'y a qu'une seule copie d'une constante de chaîne dans le pool de constantes.

Et quand il s'agit de pools partagés, on peut facilement penser au pool de connexions JDBC en Java Grâce à la gestion du pool de connexions, le partage des connexions à la base de données est réalisé, et la connexion n'a pas besoin d'être recréée à chaque fois. du temps, économisant le coût de recréation de la base de données, améliorant les performances du système !

Détails du modèle de poids mouche : type structurel de modèle de conception Java : modèle de poids mouche

Plus tôt, nous avons introduit 7 modèles de conception structurels, nous introduisons ensuite 11 modèles de conception comportementaux : modèle de stratégie, modèle de méthode de modèle, modèle d'observateur, modèle d'itérateur, chaîne de modèle de responsabilité, modèle de commande, modèle de mémo, modèle d'état, modèle de visiteur, modèle de médiateur, modèle d'interprète. Prenons d'abord une photo pour voir la relation entre ces 11 modèles :

13. Modèle de stratégie comportementale :

Extrayez les parties de la classe qui changent fréquemment ou peuvent changer en tant que classe d'interface de stratégie abstraite, puis utilisez The class contient une instance de cet objet, afin que l'instance de classe puisse librement appeler le comportement de la classe qui implémente cette interface au moment de l'exécution.

Par exemple, définir une série d'algorithmes, encapsuler chaque algorithme et les rendre interchangeables, afin que l'algorithme puisse changer indépendamment des clients qui l'utilisent, tel est le modèle de stratégie. Le diagramme de structure UML est le suivant :

L'avantage du modèle de stratégie est qu'il peut modifier dynamiquement le comportement de l'objet mais l'inconvénient est que de nombreuses classes de stratégie seront générées, et le pouvoir décisionnel de le modèle de stratégie appartient à l'utilisateur. Le système fournit uniquement la mise en œuvre de différents algorithmes, les clients Duan doivent donc connaître toutes les classes de stratégie et décider quelle classe de stratégie est utilisée par lui-même ;

le mode de stratégie est applicable pour les scènes suivantes :

(1) L'application doit implémenter des services fonctionnels spécifiques et le programme dispose de plusieurs méthodes d'implémentation, il doit donc choisir dynamiquement l'un des nombreux algorithmes
(2) Une classe définit plusieurs algorithmes comportementaux, et si ces comportements apparaissent dans sous la forme de plusieurs instructions conditionnelles dans le fonctionnement de la classe, les branches conditionnelles pertinentes peuvent être déplacées dans leurs classes de stratégie respectives pour remplacer ces instructions conditionnelles.

Détails du modèle de stratégie : Modèle de conception comportemental Java : Modèle de stratégie

14 Méthode de modèle comportemental :

La méthode de modèle est implémentée sur la base de l'héritage Déclarez une méthode de modèle dans la classe parent abstraite et les étapes d'exécution. de l'algorithme (c'est-à-dire le squelette de l'algorithme) sont définis dans la méthode modèle. Dans le modèle de méthode modèle, les parties communes de la sous-classe peuvent être implémentées dans la classe parent, tandis que les parties caractéristiques sont retardées dans la sous-classe. Il vous suffit de déclarer la partie caractéristique comme méthode abstraite dans la classe parent, afin que la partie caractéristique soit déclarée comme méthode abstraite. sous-classe Certaines étapes de l'algorithme peuvent être redéfinies sans modifier la structure de l'algorithme, et différentes sous-classes peuvent implémenter ces logiques de différentes manières.

L'avantage du modèle de méthode modèle est qu'il est conforme au « principe d'ouverture et de fermeture » et peut également permettre la réutilisation du code, transférer un comportement inchangé à la classe parent et supprimer le code en double dans la sous-classe. Cependant, l'inconvénient est que différentes implémentations doivent définir une sous-classe, ce qui entraîne une augmentation du nombre de classes, rendant le système plus grand et la conception plus abstraite. Le diagramme UML du modèle de méthode modèle est le suivant :

Détails de la méthode modèle : Modèle de conception comportemental Java : Modèle de méthode modèle

15. Modèle de chaîne comportementale de responsabilité :

La chaîne de responsabilité peut attribuer. le gestionnaire de la demande Organisez-vous en chaîne et faites passer la demande tout au long de la chaîne. Si un processeur peut traiter la demande, elle sera traitée, sinon la demande sera transmise au supérieur pour traitement. Le client n'a qu'à envoyer la demande à la chaîne de responsabilité et n'a pas besoin de prêter attention aux détails du traitement de la demande. L'expéditeur et le processeur de la demande sont découplés à travers la chaîne de responsabilité. C'est également la motivation de conception de la chaîne de responsabilité.

Le modèle de chaîne de responsabilité peut simplifier l'interconnexion entre les objets, car ni le client ni le processeur n'ont d'informations claires sur l'autre partie et le processeur ne connaît pas la structure de la chaîne de responsabilité. Le processeur n'a besoin que de sauvegarder une référence. au successeur, il n'est pas nécessaire de sauvegarder les références de tous les candidats.

De plus, le modèle de chaîne de responsabilité augmente la flexibilité du système. Nous pouvons ajouter ou modifier des processeurs à volonté, et même modifier l'ordre des processeurs. Cependant, cela peut entraîner qu'une demande ne soit pas traitée de toute façon, car cela peut arriver. être placé en bout de chaîne.

Le modèle de chaîne de responsabilité présente donc les avantages suivants :

(1) Réduire le degré de couplage et découpler l'expéditeur et le destinataire de la demande. Cela se reflète dans le code, il n'est pas nécessaire d'écrire beaucoup d'instructions if...else laides dans la classe. Si la chaîne de responsabilité est utilisée, cela équivaut à nous faire face à une boîte noire. à l'un des processeurs, puis laissez la boîte noire entrer à l'intérieur. Soyez simplement responsable de sa livraison.

(2) Simplifie l'objet afin que l'objet n'ait pas besoin d'une structure de chaîne.

(3) Augmentez la flexibilité du système, permettant l'ajout ou la suppression dynamique de gestionnaires en changeant les membres au sein de la chaîne ou en déplaçant leur commande

(4) Il est pratique d'ajouter de nouvelles classes de traitement des demandes.

Mais le modèle de chaîne de responsabilité présente également certains inconvénients :

(1) Il n'y a aucune garantie que la demande sera traitée avec succès

(2) Les performances du système seront affectées dans une certaine mesure et les appels en boucle peuvent se produire.

(3) Il peut ne pas être facile d'observer les caractéristiques d'exécution, et c'est gênant lors du débogage du code, ce qui gêne le débogage.

Le diagramme de structure UML du modèle de chaîne de responsabilité est le suivant :

Détails du modèle de chaîne de responsabilité : Type comportemental du modèle de conception Java : modèle de chaîne de responsabilité

16. :

Observer Le modèle, également connu sous le nom de modèle de publication-abonnement, définit une relation de dépendance un-à-plusieurs entre les objets. Lorsque l'état de l'objet cible (observateur) change, toutes ses dépendances (observateurs) seront notifiées. Une cible d'observation peut correspondre à plusieurs observateurs, et ces observateurs ne sont pas liés les uns aux autres, de sorte que les observateurs peuvent être ajoutés et supprimés selon les besoins, ce qui rend le système plus facile à étendre et à respecter le principe d'ouverture et de fermeture et le mode observateur permet le ; Objet cible et observation Les observateurs sont faiblement couplés. Bien que les uns ne connaissent pas les détails de l'autre, ils peuvent toujours interagir. L'objet cible ne connaît qu'une liste d'observateurs spécifique, mais ne connaît aucun observateur spécifique. ils ont tous une interface commune.

Mais l'inconvénient du modèle d'observateur est que s'il y a de nombreux observateurs, il faudra un certain temps pour notifier tous les observateurs. S'il existe une dépendance circulaire entre l'observateur et l'observé, cela peut provoquer un crash du système. et Le modèle d'observateur n'a pas de mécanisme correspondant permettant à l'observateur de savoir comment l'objet observé a changé, mais seulement de savoir que la cible d'observation a changé. Le diagramme de structure UML du modèle d'observateur est le suivant :

Détails du modèle d'observateur : Modèle de conception comportemental Java : Modèle d'observateur

17 Modèle comportemental-visiteur :

Le modèle de visiteur est une méthode de séparation d'objet. structure et comportement des données (opérations basées sur des structures de données). Grâce à cette séparation, l'effet d'ajouter dynamiquement de nouvelles opérations à un visiteur sans apporter d'autres modifications est obtenu, permettant d'ajouter de nouvelles opérations qui agissent sur ces structures de données. Il n'est pas nécessaire de modifier chaque structure de données.Il fournit plusieurs méthodes d'opération d'accès pour différents types de structures de données.C'est la motivation de conception du modèle de visiteur.

En plus de faciliter l'ajout de nouvelles opérations d'accès, vous pouvez également définir les opérations de la hiérarchie des classes sans modifier la hiérarchie des classes existante, et concentrer le comportement d'accès des objets éléments associés dans un objet visiteur au lieu de les répartir. un par un dans les classes d'éléments.

Mais l'inconvénient du modèle visiteur est qu'il rend difficile l'ajout de nouvelles classes d'éléments. Chaque ajout d'une nouvelle classe d'éléments signifie l'ajout d'une nouvelle opération abstraite au rôle de visiteur abstrait, et l'ajout d'une nouvelle opération abstraite à chaque visiteur spécifique.

L'ajout d'opérations spécifiques correspondantes à la classe viole les exigences du « principe d'ouverture et de fermeture » ; le modèle de visiteur convient donc aux systèmes qui modifient rarement la structure de l'objet, mais qui ont souvent besoin de définir de nouvelles opérations sur cette structure d'objet ; l'algorithme L'ajout d'opérations devient simple ; soit il est nécessaire d'effectuer de nombreuses opérations différentes et sans rapport sur une structure d'objet, et il faut éviter de laisser ces opérations polluer ces objets, et on ne veut pas modifier ces classes lors de l'ajout de nouvelles opérations. .

' ' s ' s ' s . Les visiteurs et les visiteurs spécifiques, principalement utilisés pour déclarer certaines opérations ; l'un est la hiérarchie des éléments, qui fournit des éléments abstraits et des éléments concrets, principalement utilisés pour déclarer les opérations d'acceptation et les ; structure de l'objet ObjectStructure sert de pont entre les deux, stockant différents types d'objets, de sorte que différents visiteurs puissent y accéder, et que le même visiteur puisse accéder à différents éléments de différentes manières, donc l'ajout de nouveaux visiteurs en mode visiteur ne nécessite pas de modifier l'existant. code et peut être étendu. ? à utiliser en mode visiteur. En mode visiteur, le client transmet le statut spécifique comme paramètre au visiteur spécifique. La première expédition est terminée ici, puis le visiteur spécifique est utilisé comme paramètre dans la méthode "statut spécifique", et le sien est également. passé en paramètre, la deuxième répartition est terminée ici. La double expédition signifie que l'exécution qui en résulte dépend du type de demande et du type de destinataire.

Détails du modèle de visiteur : modèle de conception comportementale Java : modèle de visiteur

18. Modèle de médiateur comportemental :

use use ’ ’ ’ ’ use ’ s ’ ’ pour la structure complexe du réseau des relations entre les objets devient une simple structure en étoile avec un intermédiaire comme noyau, et la relation un-à-plusieurs entre les objets se transforme en une relation un-à-un, simplifiant la relation entre les objets et la rendant plus facile à comprendre ; La relation est découplée et chaque objet n'interagit plus directement avec ses objets associés, mais communique avec les objets associés via l'objet intermédiaire, de sorte que les objets peuvent être utilisés de manière relativement indépendante, améliorant ainsi la réutilisabilité des objets et l'évolutivité du système.中 En mode intermédiaire, la classe intermédiaire est en position centrale. Elle encapsule la relation entre toutes les classes d'objets du système, en plus de simplifier la relation entre les objets, elle peut également contrôler davantage l'interaction entre les objets. Le diagramme de structure UML du modèle médiateur est le suivant :

Cependant, l'objet médiateur encapsule la relation entre les objets, ce qui le rend plus grand et plus complexe, porte plus de responsabilités et est plus difficile à maintenir. Il a besoin de connaître chaque objet et les détails de l'interaction entre eux, le cas échéant. va mal, cela entraînera un dysfonctionnement de tout le système.

Détails du modèle de médiateur : Modèle de conception comportemental Java : Modèle de médiateur

19 Modèle de commande comportementale :

L'essence du modèle de commande est d'encapsuler les requêtes dans des objets et d'attribuer la responsabilité d'émettre des commandes et de les exécuter séparément. , l'expéditeur et le destinataire de la commande sont complètement découplés. L'expéditeur a seulement besoin de savoir comment envoyer la commande et n'a pas besoin de se soucier de la manière dont la commande est implémentée, ni même de savoir si elle est exécutée avec succès. La clé du mode commande est l'introduction d'une interface de commande abstraite. Les programmes émetteurs pour l'interface de commande abstraite peuvent être associés au récepteur.

L'avantage d'utiliser le mode commande est qu'il réduit le couplage du système, et de nouvelles commandes peuvent être facilement ajoutées au système, et il est également facile de concevoir une commande combinée. Mais l’inconvénient est que certains systèmes auront trop de classes de commandes spécifiques, car une classe de commandes spécifique doit être conçue pour chaque commande.

Le diagramme de structure UML du modèle de commande est le suivant :

Détails du modèle de commande : Type comportemental du modèle de conception Java : Modèle de commande

20. Mode d'état comportemental :

En modifiant son comportement lorsque l'état change, l'objet semble avoir modifié sa classe, c'est-à-dire changer de comportement en utilisant l'état comme un atome, plutôt que de changer d'état par le comportement.

Lorsque le comportement d'un objet dépend de ses attributs, on appelle ces attributs état, et l'objet est appelé objet d'état. Pour un objet d'état, son comportement dépend de son état. Par exemple, si vous souhaitez réserver une chambre, vous ne pouvez la réserver que lorsque la chambre est libre. Vous ne pouvez vous enregistrer dans la chambre que lorsque vous avez réservé la chambre ou la chambre. est gratuit. Pour un tel objet, lorsque ses événements externes interagissent, son état interne change, entraînant un changement de comportement en conséquence.

Le diagramme de structure UML du modèle d'état est le suivant :

À partir du diagramme de structure UML ci-dessus, nous pouvons voir que les avantages du modèle d'état sont :

(1) Encapsule les règles de conversion, permettant le logique de conversion d'état à intégrer à l'objet d'état, au lieu d'un énorme bloc d'instructions conditionnelles

(2) Mettez tous les comportements liés à l'état dans une classe, vous pouvez facilement ajouter de nouveaux états et il vous suffit de changer l'état de l'objet pour changer le comportement de l'objet.

Mais les inconvénients du modèle d'état sont :

(1) Le type d'état doit être déterminé avant d'énumérer les états

(2) Cela entraînera une augmentation du nombre de classes et d'objets système.

(3) La prise en charge du "principe d'ouverture-fermeture" n'est pas conviviale. L'ajout d'une nouvelle classe d'état nécessite de modifier le code source responsable de la conversion d'état, sinon il ne peut pas passer au nouvel état et au comportement de modification d'un certain état. La classe d'état doit également être modifiée. Le code source de la classe correspondante.

Le modèle d'état convient donc pour : le code contient un grand nombre d'instructions conditionnelles liées à l'état de l'objet, et le comportement de l'objet dépend de son état, et son comportement associé peut être modifié en fonction des changements dans son état. État. ： Détails du mode d'état : type de comportement du mode de conception Java : mode statut

21, mode mémo comportemental :

Le mode mémorandum fournit un mécanisme de récupération de l'état interne à un certain moment est enregistré en dehors de l'objet pour garantir que l'état interne est enregistré à l'extérieur de l'objet. l'objet peut être restauré à un certain état historique ; le mode mémo encapsule les détails enregistrés dans le mémo, et aucun autre objet ne peut y accéder à l'exception du créateur qui l'a créé, et permet que même si les détails enregistrés sont modifiés, le client. ne sera pas affecté. Cependant, le mode mémo est multi-états et multi-sauvegarde, ce qui utilisera plus de mémoire et consommera des ressources. Le diagramme de structure UML du modèle mémo est le suivant :

Le cœur du mode Mémorandum est Mémation MEMENTO. Dans le mémorandum, il s'agit d'une partie ou de la totalité des informations d'état de l'organe d'origine. Les objets externes sont utilisés pour stocker ces informations d'état. Si les informations d'état internes sont exposées, cela viole le. principe d'encapsulation. Par conséquent, le mémo n'est pas accessible aux autres objets, à l'exception de l'expéditeur. Ainsi, afin de mettre en œuvre l'encapsulation du mode mémo, nous devons contrôler l'accès au mémo :

(1) Pour l'expéditeur : toutes les informations contenues dans le mémo sont accessibles.

(2) Pour le responsable, gardien : Les données du mémo ne sont pas accessibles, mais il peut sauvegarder le mémo et transmettre le mémo à d'autres objets.

(3) Autres objets : inaccessibles et non sauvegardés. Il est uniquement responsable de la réception du mémo transmis par le responsable et de la restauration de l'état de l'appareil d'origine.

Détails du modèle Memento : modèle de conception comportemental Java : modèle Memento

22. Modèle d'itérateur comportemental :

Le modèle Iterator fournit un moyen d'accéder aux éléments individuels d'une collection sans exposer sa méthode de représentation interne. Donnez la responsabilité de parcourir les éléments aux itérateurs plutôt qu'aux objets de collection, simplifiant ainsi la mise en œuvre des conteneurs de collection et permettant au conteneur de collection de se concentrer sur ce sur quoi il doit se concentrer, ce qui est plus conforme au principe de responsabilité unique et évite d'avoir à La couche d'interface abstraite est remplie de diverses opérations de traversée différentes. Le diagramme de structure UML du modèle d'itérateur est le suivant :

Détails du modèle d'itérateur : Type comportemental du modèle de conception Java : Modèle d'itérateur

23 Type comportemental - modèle d'interpréteur :

Le modèle d'interpréteur est le. définition La grammaire d'une langue et construire un interprète pour interpréter les phrases dans la langue. En construisant l'interprète, résolvez un type spécifique d'instance de problème qui se produit fréquemment. ? et comment interpréter ces phrases. En mode interprète, en plus d'utiliser des règles grammaticales pour définir un langage, les arbres de syntaxe abstraite peuvent également être utilisés pour représenter de manière plus intuitive et mieux représenter la composition d'un langage. Chaque arbre de syntaxe abstraite correspond à une instance de langage. L'arbre de syntaxe abstraite décrit comment former une phrase complexe. En analysant l'arbre de syntaxe abstraite, les classes de symboles terminaux et non terminaux du langage peuvent être identifiées. En mode interprète, puisque chaque expression terminale et expression non terminale a une instance spécifique qui lui correspond, le système a une meilleure évolutivité.

L'UML du modèle d'interpréteur est le suivant :

Détails du modèle d'interprète : Type comportemental du modèle de conception Java : Modèle d'interprète