Introduction aux modèles de conception Java

Ce résumé est principalement basé sur ma précédente série d'articles sur les bases des modèles de conception. L'essentiel est d'expliquer les points de connaissances importants dans mes propres mots. Il peut y avoir des erreurs, j'espère donc que vous pourrez me pardonner et me donner quelques conseils.

Modèle de conception

Modèle créatif

Le rôle du modèle de création est de créer un objet. Lorsqu'il s'agit de créer un objet, la chose la plus courante est de créer un nouvel objet, puis de définir les attributs associés. Cependant, dans de nombreux scénarios, nous devons fournir aux clients un moyen plus convivial de créer des objets, en particulier lorsque nous définissons des classes mais que nous devons les fournir à d'autres développeurs.

Boîtier unique

单例模式保证全局的单例类只有一个实例，这样的话使用的时候直接获取即可，比如数据库的一个连接，Spring里的bean，都可以是单例的。

单例模式一般有5种写法。

第一种是饿汉模式，先把单例进行实例化，获取的时候通过静态方法直接获取即可。缺点是类加载后就完成了类的实例化，浪费部分空间。

第二种是饱汉模式，先把单例置为null，然后通过静态方法获取单例时再进行实例化，但是可能有多线程同时进行实例化，会出现并发问题。

第三种是逐步改进的方法，一开始可以用synchronized关键字进行同步，但是开销太大，而后改成使用volatile修饰单例，然后通过一次检查判断单例是否已初始化，如果未初始化就使用synchronized代码块，再次检查单例防止在这期间被初始化，而后才真正进行初始化。

第四种是使用静态内部类来实现，静态内部类只在被使用的时候才进行初始化，所以在内部类中进行单例的实例化，只有用到的时候才会运行实例化代码。然后外部类再通过静态方法返回静态内部类的单例即可。

第五种是枚举类，枚举类的底层实现其实也是内部类。枚举类确保每个类对象在全局是唯一的。所以保证它是单例，这个方法是最简单的。

Modèle d'usine

简单工厂一般是用一个工厂创建多个类的实例。

工厂模式一般是指一个工厂服务一个接口，为这个接口的实现类进行实例化

抽象工厂模式是指一个工厂服务于一个产品族，一个产品族可能包含多个接口，接口又会包含多个实现类，通过一个工厂就可以把这些绑定在一起，非常方便。

Motif prototype

一般通过一个实例进行克隆从而获得更多同一原型的实例。使用实例的clone方法即可完成。

Modèle de constructeur

建造者模式中有一个概念叫做链式调用，链式调用为一个类的实例化提供便利，一般提供系列的方法进行实例化，实际上就是将set方法改造一下，将原本返回为空的set方法改为返回this实例，从而实现链式调用。

建造者模式在此基础上加入了builder方法，提供给外部进行调用，同样使用链式调用来完成参数注入。

Modèle structurel

Le modèle de création précédent a introduit certains modèles de conception pour la création d'objets. La structure présentée dans cette section Le modèle. vise à réaliser le découplage en modifiant la structure du code, rendant notre code plus facile à maintenir et à développer.

Modèle d'adaptateur

Le modèle d'adaptateur est utilisé pour adapter deux classes différentes.

Similarités et différences entre le mode adaptateur et le mode proxy

Comparer ces deux modes revient en fait à comparer le mode adaptateur objet et le mode proxy,

Ils sont très. similaires. Tous nécessitent une instance d’une classe d’implémentation spécifique.

Mais leurs objectifs sont différents. Le mode proxy fait le travail d'amélioration de la méthode originale

L'adaptateur fait le travail d'adaptation, afin de fournir « emballer le poulet dans le canard, puis l'utiliser ; comme un canard",

Il n'y a pas de lien d'héritage entre les poules et les canards.

Le modèle d'adaptateur peut être divisé en adaptateur de classe, adaptateur d'objet, etc.

Un adaptateur de classe peut s'adapter à la classe parent en héritant de la classe parent.

L'adaptateur d'objet doit transmettre l'objet au constructeur d'un autre objet pour l'empaquetage.

Mode poids mouche

/ Le cœur du mode poids mouche est la classe d'usine de poids mouche,

// La fonction de la classe d'usine de poids mouche est de fournir un pool de poids mouche utilisé pour stocker des objets poids mouche,

// Lorsque l'utilisateur a besoin d'un objet, obtenez-le d'abord dans le pool de poids mouche,

// S'il n'existe pas dans le pool de poids mouche , créez-le Un nouvel objet flyweight est renvoyé à l'utilisateur,

// Enregistrez le nouvel objet dans le pool flyweight.

//Flyweight Pattern

// L'anglais est Flyweight Pattern. Je ne sais pas qui a traduit ce mot en premier. Je pense que cette traduction est vraiment difficile à comprendre. connexion. Flyweight signifie léger. Flyweight fait référence à des composants partagés, c'est-à-dire à la réutilisation d'objets déjà générés. Cette approche est bien sûr légère.

// Le moyen le plus simple de réutiliser des objets est d'utiliser un HashMap pour stocker chaque objet nouvellement généré. Chaque fois que vous avez besoin d'un objet, accédez d'abord au HashMap pour voir s'il existe. Sinon, générez un nouvel objet, puis placez cet objet dans le HashMap.

// Je ne démontrerai pas ce code simple.

Mode proxy

// Nous avons constaté qu'une telle chose n'existe pas, pour le dire franchement, le mode proxy consiste à faire du « packaging de méthodes » ou une « amélioration de méthodes ». ".

// En programmation orientée aspect, oubliez ce terme En AOP,

// est en fait le processus de proxy dynamique. Par exemple, au Spring,

// nous ne définissons pas nous-mêmes la classe proxy, mais Spring nous aidera à définir dynamiquement le proxy,

// puis à nous définir dans @Before, @After, @Around La logique du code est ajoutée dynamiquement à l'agent.

Mode Apparence

Le mode Apparence encapsule généralement des détails d'implémentation spécifiques pour fournir aux utilisateurs une interface plus simple.

Vous pouvez obtenir le contenu requis via un appel de méthode.

Mode composition

//Le mode combinaison est utilisé pour représenter les données avec une structure hiérarchique, rendant cohérent notre accès aux objets uniques et aux objets combinés.

//Regardons directement un exemple. Chaque employé a des attributs tels que le nom, le service et le salaire

// Il existe également une collection d'employés subordonnés (bien que la collection puisse l'être). vide),

// La structure des employés subordonnés est la même que la nôtre,

// a également des attributs tels que le nom et le département,

// a également une collection de leurs employés subordonnés.

class Employee {
    private String name;
    private String dept;
    private int salary;
    private List<Employee> subordinates; // 下属
}

Modèle de décorateur

Décorateur

Le modèle de décorateur permet à chaque classe améliorée d'hériter de la classe parent de plus haut niveau. Ensuite, lorsqu'une amélioration des fonctionnalités est nécessaire, transmettez simplement l'instance de classe dans la classe améliorée, et la classe améliorée peut alors améliorer les fonctionnalités de la classe d'origine lorsqu'elle est utilisée.

Différent du mode proxy, en mode décorateur, chaque classe de décoration hérite de la classe parent et peut être encapsulée à plusieurs niveaux.

Modèle comportemental

Le modèle comportemental se concentre sur l'interaction entre les différentes classes, divisant clairement les responsabilités et rendant notre code plus clair.

Modèle de stratégie

Le modèle de stratégie considère généralement une stratégie comme une classe et la transmet dans l'instance où la stratégie doit être spécifiée, nous pouvons donc utiliser l'algorithme où Transmettez l’algorithme spécifié.

Mode Commande

Le mode commande est généralement divisé en trois rôles : initiateur de commande, commande et récepteur de commande.

L'initiateur de la commande doit injecter l'instance de commande lors de son utilisation. Exécutez ensuite l’appel de commande.

L'appel de commande appelle en fait la méthode du récepteur de commande pour effectuer l'appel réel.

Par exemple, un bouton de la télécommande équivaut à une commande. Lorsque le bouton est cliqué, la commande est exécutée et la méthode fournie par le téléviseur est automatiquement appelée.

Modèle de méthode modèle

La méthode modèle fait généralement référence à la fourniture d'un modèle de méthode, qui contient des classes d'implémentation et des classes abstraites, et spécifie l'ordre d'exécution.

Les classes d'implémentation sont de bonnes méthodes fournies par les modèles. Les classes abstraites nécessitent que les utilisateurs les implémentent eux-mêmes.

Les méthodes de modèle spécifient l'ordre d'exécution des méthodes dans un modèle, ce qui est très approprié pour certains frameworks de développement, de sorte que les méthodes de modèle sont également largement utilisées dans les frameworks open source.

Modèle d'observateur et mécanisme d'écoute des événements

Le modèle d'observateur est généralement utilisé pour l'abonnement aux données entre les abonnés et les éditeurs de messages.

Généralement divisés en observateurs et sujets. Les observateurs s'abonnent aux sujets et enregistrent les instances dans la liste d'observateurs maintenue par le sujet.

Lorsque le sujet met à jour les données, il transmet automatiquement les données à l'observateur ou informe l'observateur que les données ont été mises à jour.

Mais en raison de cette méthode, la relation de couplage du message push est relativement étroite. Et il est difficile de savoir quel est le type de données sans ouvrir les données.

Je sais que afin de rendre le format des données plus flexible, les modèles d'événement et d'écouteur d'événement ont été utilisés. Le type d'événement et les données d'événement du wrapper d'événement ont été découplés du sujet et de l'observateur.

Lorsqu'un événement se produit, le thème déclenche tous les auditeurs de l'événement et envoie l'événement à chaque auditeur via la liste des auditeurs. Après avoir écouté l'événement, il trouve d'abord le type d'événement correspondant en fonction du type d'événement. il prend en charge le gestionnaire d'événements, puis utilisez le gestionnaire pour traiter l'événement correspondant.

Modèle de chaîne de responsabilité

La chaîne de responsabilité doit généralement établir d'abord une liste chaînée unidirectionnelle, puis l'appelant n'a qu'à appeler le nœud principal, et il coulera automatiquement plus tard. Par exemple, l'approbation du processus est un bon exemple. Tant que l'utilisateur final soumet une candidature, une chaîne de responsabilité sera automatiquement établie en fonction des informations sur le contenu de la candidature, puis le flux pourra commencer

.

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!