Modèles de conception courants en JAVA

Cet article partage principalement avec vous les modèles de conception courants de JAVA. Les amis qui en ont besoin peuvent y jeter un œil.

J'ai été exposé très tôt aux modèles de conception. Quand j'ai lu certains articles aujourd'hui, j'ai découvert que j'avais quelques écarts dans l'apprentissage et la compréhension des modèles de conception. Les modèles de conception doivent servir à des scénarios spécifiques et sont des idées de solutions de code résumées à partir d'expériences antérieures. Cette idée de solution examine comment réduire le couplage entre les codes et réduire la redondance, ce qui rend les codes couplés. Le but d'un degré inférieur est une meilleure expansion du programme. La soi-disant meilleure expansion fait référence au déclenchement du moins de changements possible lorsque la fonction est modifiée ou étendue. Par conséquent, lors de l'apprentissage des modèles de conception, une bonne façon d'apprendre devrait être de simuler l'extension du programme pour comparer les différences entre les modèles de conception résumés par les prédécesseurs et le code existant. Ce n'est qu'en réalisant réellement ses avantages que nous pourrons pleinement comprendre son essence. .

Creative Patterns

Creative Pattern résume le processus d'instanciation des objets, ce qui aide un système à être indépendant de la façon dont ces objets sont créés, composés et représentés.

Modèle d'usine abstrait

Le modèle d'usine abstrait est utilisé pour créer des usines avec différentes familles de produits. La soi-disant famille de produits vaut plusieurs valeurs différentes. objets Les valeurs des différents objets sont relatives aux objets qui implémentent la même interface, donc les objets de la même famille de produits n'implémentent certainement pas la même interface.

Le modèle d'usine abstraite comprend 7 rôles principaux, un rôle abstrait de classe A et un rôle concret de classe A (AbstractProductA, ProductA), un rôle abstrait de classe B et un rôle concret de classe B (AbstractProductB, ProductB), Abstract Factory (AbstractFactory) Fournit deux interfaces de méthode pour les produits de type A et les produits de type B. La fabrique concrète (ConcreteFactory) implémente les deux interfaces de méthode de la fabrique abstraite. L'implémentation des deux interfaces de méthode dépend de différents produits A et B (createProductA est dérivé de l'implémentation. classe de produit A Sélectionnez une classe d'implémentation dans la classe d'implémentation, createProductB sélectionne une classe d'implémentation dans la classe d'implémentation du produit B). Le client s'appuie sur la classe d'implémentation spécifique de l'usine abstraite pour produire les produits d'une famille de produits d'une usine spécifique.

Le modèle d'usine abstrait implémente la fourniture d'usines de familles de produits pour plusieurs produits et réalise des combinaisons multidimensionnelles de plusieurs produits. Un exemple typique de familles de produits est UnixButton et WindowsButton. Disponible en usine pour différentes combinaisons de produits. Du point de vue de l'expansion, l'usine concrète implémente l'usine abstraite. Si une nouvelle famille de produits est nécessaire, il suffit d'implémenter une autre famille de produits, en réalisant un échange à chaud. En comparant le modèle d’usine, une usine concrète fait face à un produit, tandis qu’une usine abstraite fait face à une série de produits.

Builder Pattern

Le rôle du Builder Pattern est d'abstraire les étapes de construction d'un objet, le rendant ainsi facile à réécrire un objet Processus de construction d'un objet.

Le modèle de constructeur comprend 4 rôles principaux, l'interface du constructeur (Builder), le constructeur concret (ConcreteBuilder), l'objet produit (Product) et la classe directeur (Director). La méthode construct de la classe directrice est chargée d'appeler plusieurs méthodes buildPart du constructeur abstrait pour l'assemblage. L'interface Builder définit plusieurs méthodes de processus de construction partielle buildPart() et des méthodes de résultat de construction retrieveResult() que les constructeurs concrets doivent implémenter. méthodes de construction et Dans la méthode de retour du résultat, le constructeur spécifique termine la tâche d'assemblage correspondante et utilise retrieveResult pour obtenir le résultat d'assemblage correspondant.

D'un point de vue objectif, le modèle de constructeur réalise l'implémentation la plus simple de différentes méthodes d'assemblage d'objets. L'ordre d'assemblage est contrôlé par la classe directeur et les tâches d'assemblage spécifiques sont réparties entre les mains de différents constructeurs. et résumé La relation d'agrégation des constructeurs rend le fonctionnement réel de la construction du produit échangeable à chaud, ce qui rend la mise en œuvre spécifique de la construction plus facile à étendre ou à remplacer. D'un autre côté, si vous utilisez la classe directeur pour faire fonctionner directement le produit afin de mettre en œuvre le processus d'assemblage du produit, et si vous devez modifier le processus de construction, vous devez modifier la classe directeur, ce que nous ne voulons pas voir .

Structural Pattern

Structural Pattern se concentre sur la façon d'assembler des classes existantes et de concevoir les interactions entre elles pour atteindre certains objectifs, tels que l'évolutivité et l'encapsulation.

Modèle d'adaptateur

Le but du modèle d'adaptateur est de convertir l'interface de méthode d'une classe en une autre interface de méthode qui sera utilisée par un autre client.

Le modèle d'adaptateur contient trois rôles principaux, l'interface cible (Target) requise par le client et sa méthode sampleOperation(); la classe adaptée Adaptee, qui est l'exécuteur réel Adapter, dont l'Adaptateur hérite ; Interface cible et hérite d'Adaptee, la méthode sampleOperation de l'adaptateur appelle la méthode sampleOperation d'Adptee. En fait, la méthode de classe Adaptee peut être appelée par héritage ou par dépendance directe. La première est appelée adaptateur de classe et la seconde est appelée adaptateur d'objet.

Le modèle d'adaptateur implémente la conversion de compatibilité d'une interface à une autre. Il n’y a rien de spécial en matière d’évolutivité.

Modèle décorateur

Le modèle décorateur est également appelé modèle d'emballage. Son objectif est d'étendre dynamiquement les fonctionnalités d'une classe sans modifier la relation d'héritage d'origine. Les fonctions des classes étendues mentionnées ici peuvent être des modifications apportées aux méthodes existantes, ou elles peuvent fournir davantage de méthodes.

Le modèle de décorateur contient 4 rôles principaux, la relation d'héritage qui existe déjà dans le système, l'interface du composant (Component) et sa classe d'implémentation (ConcreteComponent), et le décorateur (Decorator) implémente l'interface du composant et dépend sur le béton à décorer. Classe d'implémentation, sa méthode sampleOperation() dépend de la méthode sampleOperation() de la classe de composant spécifique à décorer, puis le décorateur spécifique (ConcreateDecorator) hérite de Decorator, qui peut ajouter d'autres méthodes ou modifier la méthode correspondante. méthode sampleOperation, réalisant ainsi différents Changez la classe d'origine et implémentez la même extension de méthode dynamique, et cette extension est transparente pour le client.

Du point de vue de l'extension, Decorator remplace le ConCreteComponent d'origine et le remplace pour compléter l'expansion dynamique de l'héritage. Par rapport à l'héritage direct de ConcreteComponent, cette méthode a des dépendances plus petites sur les objets qu'elle décore. branché et débranché, et ConcreteComponent n'a pas besoin de connaître l'existence de classes décoratives, éliminant ainsi le besoin de maintenir des relations de classe complexes.

Un exemple spécifique d'application est la relation entre BufferInputStream et FileInputStream. InputStream est un composant, FileInputStream, ByteArrayInputStream, etc. sont des composants spécifiques. .

Modèle de proxy

Le but du modèle de proxy est de fournir un proxy pour un objet L'objet proxy peut améliorer, modifier. ou même supprimer l'original Certaines fonctions.
Le mode proxy étant largement utilisé, le mode proxy a été décrit en détail dans un autre blog et ne sera pas redondant ici.

Modèle structurel

Le modèle de conception structurelle se concentre sur la répartition des responsabilités entre les classes ou les objets et étudie comment plusieurs classes ou objets peuvent coopérer efficacement pour accomplir une tâche.

Modèle d'observateur

Le but du modèle d'observateur est d'implémenter une relation de dépendance un-à-plusieurs, de sorte que lorsque le sujet est mis à jour, la mise à jour puisse être notifiée dans un manière spécifique.

Le modèle observateur contient 4 participants, une interface thématique et un sujet d'implémentation spécifique (Subject, ConcreteSubject), un observateur et un observateur concret (Observer, ConcreateObserver). Les observateurs sont enregistrés dans le sujet via l'agrégation. Grâce à l'interface de définition des dépendances, des sujets spécifiques peuvent implémenter différentes stratégies de notification et des dépendances à faible couplage peuvent être obtenues entre des observateurs spécifiques et des sujets spécifiques.
La dépendance entre les deux peut être établie et libérée via les méthodes d'attachement et de détachement. Lorsque le sujet change d'état, il peut avertir tous les observateurs via notifyObserver et appeler la méthode de mise à jour de l'observateur correspondant.
Du point de vue de l'expansion, l'avantage du modèle d'observateur est que lors de l'ajout d'un nouvel observateur, il vous suffit d'implémenter l'interface de l'observateur, puis de l'ajouter en l'attachant au sujet spécifique que vous souhaitez surveiller de la même manière, si ; vous souhaitez supprimer Un observateur dans un sujet n'a besoin que d'appeler la méthode attach pour implémenter l'échange à chaud. Si cette méthode de conception n'est pas adoptée, l'incapacité de l'une ou l'autre des parties à utiliser l'interface entraînera des difficultés pour ajouter une partie.

Modèle Médiateur

Le rôle du modèle Médiateur est d'utiliser un objet intermédiaire pour encapsuler l'interaction d'une série d'objets, afin que l'interaction de chaque objet ne nécessite pas d'interaction explicite interdépendance. Pour faire simple, il s'agit de convertir l'interaction entre différents objets d'une association de maillage plusieurs-à-plusieurs en une association d'étoiles un-à-plusieurs.

Le modèle de médiateur est construit selon quatre rôles principaux. L'interface du médiateur (Mediator) définit la méthode d'interaction publique modifiée (ConcreteMediator) et obtient la méthode d'interaction spécifique modifiée () ; persistance Il y a une référence au collègue qui doit être communiquée.L'implémentation spécifique de la méthode changes() dépend de la classe abstraite du collègue (Colleague) qui définit l'association entre l'interface collègue et l'interface médiateur, et fournit une méthode d'interface pour obtenir le médiateur ; concret Il peut y avoir plusieurs classes d'implémentation de collègues (ConcreteColleague), qui implémentent principalement des opérations interactives spécifiques. Les opérations interactives dépendent de la méthode modifiée de son médiateur associé. Quant à savoir pourquoi il s'agit désormais d'une relation un-à-plusieurs, à en juger par la relation entre les quatre rôles ci-dessus, chaque collègue détient une référence à un médiateur, et chaque médiateur détient des références à tous les collèges.

L'avantage du modèle médiateur est de découpler l'interaction d'objets système complexes, de sorte que lors de l'ajout ou de la suppression d'un collège, il vous suffit de modifier le médiateur intermédiaire. Le médiateur peut également être remplacé par un autre médiateur spécifique et remplacer le comportement d'interaction correspondant. L’inconvénient est qu’à mesure que le nombre de collègues devant interagir continue d’augmenter, le nombre d’intermédiaires spécifiques continuera à augmenter.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!