Les modèles de conception représentent les meilleures pratiques utilisées par les développeurs de logiciels orientés objet expérimentés. Les modèles de conception sont des solutions aux problèmes généraux auxquels les développeurs de logiciels ont été confrontés lors du développement de logiciels. Ces solutions ont été obtenues par essais et erreurs par de nombreux développeurs de logiciels sur une période assez longue.
En 1994, quatre auteurs Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides ont publié un livre intitulé Design Patterns - Elements of Reusable Object-Oriented Software qui a lancé le concept de Design Pattern dans le développement logiciel. Ces auteurs sont connus sous le nom de Gang of Four (GOF).
Les modèles de conception peuvent être classés en trois catégories: modèles créatifs, structurels et comportementaux.
Creational Patterns- Ces modèles de conception fournissent un moyen de créer des objets tout en masquant la logique de création, plutôt que d'instancier des objets directement à l'aide d'un nouvel opérateur. Cela donne au programme plus de flexibilité pour décider quels objets doivent être créés pour un cas d'utilisation donné.
Structural Patterns- Ces modèles de conception concernent la composition des classes et des objets. Le concept d'héritage permet de composer des interfaces et de définir des manières de composer des objets pour obtenir de nouvelles fonctionnalités.
Behavioral Patterns - Ces modèles de conception concernent spécifiquement la communication entre les objets.
Ces modèles de conception concernent spécifiquement le niveau de présentation. Ces modèles sont identifiés par Sun Java Center.
Le modèle d'usine est l'un des modèles de conception les plus utilisés en Java. Ce type de modèle de conception fait partie du modèle de création car ce modèle fournit l'un des meilleurs moyens de créer un objet.
Dans le modèle Factory, nous créons un objet sans exposer la logique de création au client et faisons référence à un objet nouvellement créé à l'aide d'une interface commune.
Les modèles d'usine abstraite fonctionnent autour d'une super-usine qui crée d'autres usines. Cette usine est également appelée usine d'usines. Ce type de modèle de conception fait partie du modèle de création car ce modèle fournit l'un des meilleurs moyens de créer un objet.
Dans le modèle Abstract Factory, une interface est responsable de la création d'une fabrique d'objets associés sans spécifier explicitement leurs classes. Chaque usine générée peut donner les objets selon le modèle Factory.
Le modèle Singleton est l'un des modèles de conception les plus simples de Java. Ce type de modèle de conception fait partie du modèle de création car ce modèle fournit l'un des meilleurs moyens de créer un objet.
Ce modèle implique une seule classe qui est responsable de la création d'un objet tout en s'assurant qu'un seul objet est créé. Cette classe fournit un moyen d'accéder à son seul objet auquel il est possible d'accéder directement sans avoir besoin d'instancier l'objet de la classe.
C'est un processus en deux étapes. Tout d'abord, rendez le constructeur privé afin que l'opérateur new ne puisse pas être utilisé pour instancier la classe. Renvoyer un objet de l'objet s'il n'est pas nul, sinon créer l'objet et le renvoyer via une méthode.
Voici les différences entre une classe statique et une classe singleton.
Une classe statique ne peut pas être une classe de niveau supérieur et ne peut pas implémenter des interfaces là où une classe singleton le peut.
Tous les membres d'une classe statique sont statiques mais pour une classe Singleton, ce n'est pas une exigence.
Une classe statique est initialisée lorsqu'elle est chargée afin qu'elle ne puisse pas être chargée paresseusement là où une classe singleton peut être chargée paresseusement.
Un objet de classe statique est stocké dans la pile tandis que l'objet de classe singlton est stocké dans l'espace mémoire du tas.
Oui.
Lancez une exception dans le corps de la méthode clone ().
Voici quelques-uns des modèles de conception utilisés dans la bibliothèque JDK.
Le motif de décorateur est utilisé par les classes Wrapper.
Le modèle Singleton est utilisé par Runtime, les classes Calendar.
Le modèle d'usine est utilisé par la classe Wrapper comme Integer.valueOf.
Le modèle d'observateur est utilisé par les frameworks de gestion d'événements tels que swing, awt.
Le modèle d'usine encapsule les détails de l'implémentation et l'implémentation sous-jacente peut être modifiée sans aucun impact sur l'API de l'appelant.
Le modèle Builder crée un objet complexe à l'aide d'objets simples et en utilisant une approche étape par étape. Ce générateur est indépendant des autres objets.
Le modèle de prototype fait référence à la création d'un objet dupliqué tout en gardant à l'esprit les performances. Ce modèle implique l'implémentation d'une interface prototype qui dit de créer un clone de l'objet courant.
Ce modèle est utilisé lorsque la création directe d'objet est coûteuse. Par exemple, un objet doit être créé après une opération de base de données coûteuse. Nous pouvons mettre en cache l'objet, retourner son clone à la prochaine demande et mettre à jour la base de données au fur et à mesure des besoins, réduisant ainsi les appels à la base de données.
Le modèle d'adaptateur fonctionne comme un pont entre deux interfaces incompatibles. Ce modèle implique une seule classe qui est chargée de joindre les fonctionnalités d'interfaces indépendantes ou incompatibles.
Un exemple concret pourrait être un cas de lecteur de carte qui agit comme un adaptateur entre la carte mémoire et un ordinateur portable. Vous branchez la carte mémoire dans le lecteur de carte et le lecteur de carte dans l'ordinateur portable afin que la carte mémoire puisse être lue via un ordinateur portable.
Bridge est utilisé lorsque nous devons découpler une abstraction de son implémentation afin que les deux puissent varier indépendamment. Ce type de modèle de conception relève d'un modèle structurel car ce modèle dissocie la classe d'implémentation et la classe abstraite en fournissant une structure de pont entre elles.
Ce modèle implique une interface qui agit comme un pont qui rend la fonctionnalité des classes concrètes indépendante des classes d'implémentation d'interface. Les deux types de classes peuvent être modifiés structurellement sans s’affecter mutuellement.
Le modèle de filtre ou modèle de critère est un modèle de conception qui permet aux développeurs de filtrer un ensemble d'objets à l'aide de différents critères et de les chaîner de manière découplée via des opérations logiques. Ce type de modèle de conception relève du modèle structurel car ce modèle combine plusieurs critères pour obtenir un seul critère.
Le motif composite est utilisé lorsque nous devons traiter un groupe d'objets de la même manière comme un seul objet. Le motif composite compose des objets en termes de structure arborescente pour représenter une partie ainsi que toute la hiérarchie. Ce type de modèle de conception relève d'un modèle structurel car ce modèle crée une structure arborescente de groupe d'objets.
Ce modèle crée une classe qui contient un groupe de ses propres objets. Cette classe fournit des moyens de modifier son groupe de mêmes objets.
Le modèle Decorator permet à un utilisateur d'ajouter de nouvelles fonctionnalités à un objet existant sans modifier sa structure. Ce type de modèle de conception relève d'un modèle structurel car ce modèle agit comme un wrapper pour la classe existante.
Ce modèle crée une classe de décorateur qui encapsule la classe d'origine et fournit des fonctionnalités supplémentaires en préservant la signature des méthodes de classe.
Le modèle de façade cache les complexités du système et fournit une interface au client à l'aide de laquelle le client peut accéder au système. Ce type de modèle de conception relève d'un modèle structurel car ce modèle ajoute une interface au système existant pour masquer ses complexités.
Ce modèle implique une classe unique qui fournit les méthodes simplifiées requises par le client et délègue les appels aux méthodes des classes système existantes.
Le modèle Flyweight est principalement utilisé pour réduire le nombre d'objets créés et pour réduire l'empreinte mémoire et augmenter les performances. Ce type de modèle de conception relève d'un modèle structurel car ce modèle fournit des moyens de réduire le nombre d'objets, améliorant ainsi la structure d'objet de l'application.
Le modèle Flyweight tente de réutiliser des objets de type similaire déjà existants en les stockant et crée un nouvel objet lorsqu'aucun objet correspondant n'est trouvé.
Dans le modèle de proxy, une classe représente la fonctionnalité d'une autre classe. Ce type de modèle de conception relève du modèle structurel.
Dans le modèle de proxy, nous créons un objet ayant un objet original pour interfacer ses fonctionnalités avec le monde extérieur.
Comme son nom l'indique, le modèle de chaîne de responsabilité crée une chaîne d'objets récepteurs pour une demande. Ce modèle divise l'expéditeur et le destinataire d'une demande en fonction du type de demande. Ce modèle relève de modèles comportementaux.
Dans ce modèle, chaque récepteur contient normalement une référence à un autre récepteur. Si un objet ne peut pas gérer la demande, il la transmet au récepteur suivant et ainsi de suite.
Le modèle de commande est un modèle de conception basé sur les données et relève de la catégorie de modèle comportemental. Une demande est encapsulée sous un objet en tant que commande et transmise à l'objet appelant. L'objet invocateur recherche l'objet approprié qui peut gérer cette commande et passe la commande à l'objet correspondant qui exécute la commande.
Le modèle d'interprétation fournit un moyen d'évaluer la grammaire ou l'expression d'une langue. Ce type de modèle relève du modèle comportemental. Ce modèle implique l'implémentation d'une interface d'expression qui dit d'interpréter un contexte particulier.
Ce modèle est utilisé dans l'analyse SQL, le moteur de traitement de symboles, etc.
Le modèle d'itérateur est un modèle de conception très couramment utilisé dans l'environnement de programmation Java et .Net. Ce modèle est utilisé pour obtenir un moyen d'accéder aux éléments d'un objet de collection de manière séquentielle sans avoir besoin de connaître sa représentation sous-jacente. Le modèle d'itérateur relève de la catégorie de modèle comportemental.
Voici les entités de ce type de modèle de conception.
Service- Service réel qui traitera la demande. La référence d'un tel service doit être examinée dans le serveur JNDI.
Context / Initial Context - Le contexte JNDI porte la référence au service utilisé à des fins de recherche.
Service Locator - Service Locator est un point de contact unique pour obtenir des services par recherche JNDI mettant en cache les services.
Cache - Cache pour stocker les références des services pour les réutiliser.
Client - Le client est l'objet qui appelle les services via ServiceLocator.
Le modèle Mediator est utilisé pour réduire la complexité de la communication entre plusieurs objets ou classes. Ce modèle fournit une classe de médiateur qui gère normalement toutes les communications entre les différentes classes et prend en charge une maintenance aisée du code par couplage lâche. Le modèle de médiateur relève de la catégorie de modèle de comportement.
Le modèle Memento est utilisé pour restaurer l'état d'un objet à un état antérieur. Le modèle Memento appartient à la catégorie des modèles comportementaux.
Le modèle Memento utilise trois classes d'acteurs. Memento contient l'état d'un objet à restaurer. Originator crée et stocke des états dans des objets Memento et l'objet Caretaker est chargé de restaurer l'état de l'objet à partir de Memento.
Le modèle d'observateur est utilisé lorsqu'il existe une relation un-à-plusieurs entre des objets, par exemple si un objet est modifié, ses objets dépendants doivent être notifiés automatiquement. Le modèle d'observateur appartient à la catégorie de modèle comportemental.
Le modèle d'observateur utilise trois classes d'acteurs. Sujet, observateur et client. Le sujet est un objet ayant des méthodes pour attacher et détacher des observateurs à un objet client. Nous avons créé une classe abstraite Observer et une classe concrète Subject qui étend la classe Observer.
Dans le modèle d'état, le comportement d'une classe change en fonction de son état. Ce type de modèle de conception relève du modèle de comportement. Dans le modèle d'état, nous créons des objets qui représentent différents états et un objet de contexte dont le comportement varie à mesure que son objet d'état change.
Dans le modèle d'objet nul, un objet nul remplace la vérification de l'instance d'objet NULL. Au lieu de mettre if check pour une valeur nulle, Null Object reflète une relation ne rien faire. Un tel objet Null peut également être utilisé pour fournir un comportement par défaut au cas où les données ne seraient pas disponibles.
Dans le modèle Null Object, nous créons une classe abstraite spécifiant diverses opérations à effectuer, des classes concrètes étendant cette classe et une classe d'objet nulle fournissant une implémentation ne rien faire de cette classe et sera utilisée sans problème là où nous devons vérifier la valeur nulle.
Dans le modèle de stratégie, un comportement de classe ou son algorithme peut être modifié au moment de l'exécution. Ce type de modèle de conception relève du modèle de comportement.
Dans le modèle de stratégie, nous créons des objets qui représentent diverses stratégies et un objet de contexte dont le comportement varie selon son objet de stratégie. L'objet de stratégie modifie l'algorithme d'exécution de l'objet de contexte.
Dans le modèle de modèle, une classe abstraite expose les moyens / modèles définis pour exécuter ses méthodes. Ses sous-classes peuvent remplacer l'implémentation de la méthode selon les besoins, mais l'appel doit être de la même manière que celle définie par une classe abstraite. Ce modèle appartient à la catégorie des modèles de comportement.
Dans le modèle de visiteur, nous utilisons une classe de visiteur qui change l'algorithme d'exécution d'une classe d'élément. De cette manière, l'algorithme d'exécution de l'élément peut varier au fur et à mesure que le visiteur varie. Ce modèle appartient à la catégorie des modèles de comportement. Selon le modèle, l'objet élément doit accepter l'objet visiteur afin que l'objet visiteur gère l'opération sur l'objet élément.
MVC Pattern signifie Model-View-Controller Pattern. Ce modèle est utilisé pour séparer les préoccupations de l'application.
Model- Le modèle représente un objet ou JAVA POJO transportant des données. Il peut également avoir une logique pour mettre à jour le contrôleur si ses données changent.
View - La vue représente la visualisation des données contenues dans le modèle.
Controller- Le contrôleur agit à la fois sur le modèle et sur la vue. Il contrôle le flux de données dans l'objet modèle et met à jour la vue chaque fois que les données changent. Il maintient la vue et le modèle séparés.
Business Delegate Pattern est utilisé pour découpler le niveau de présentation et le niveau métier. Il est essentiellement utilisé pour réduire la fonctionnalité de communication ou de recherche à distance au code de niveau entreprise dans le code de niveau de présentation. Au niveau commercial, nous avons les entités suivantes.
Client - Le code de niveau de présentation peut être un code JSP, un servlet ou une interface utilisateur.
Business Delegate - Une classe de point d'entrée unique pour les entités clientes afin de fournir un accès aux méthodes Business Service.
LookUp Service - L'objet de service de recherche est chargé d'obtenir l'implémentation métier relative et de fournir l'accès aux objets métier à l'objet délégué métier.
Business Service- Interface de service aux entreprises. Les classes concrètes implémentent ce service métier pour fournir une logique d'implémentation métier réelle.
Le modèle d'entité composite est utilisé dans le mécanisme de persistance EJB. Une entité composite est un bean entité EJB qui représente un graphe d'objets. Lorsqu'une entité composite est mise à jour, les beans objets dépendants en interne sont mis à jour automatiquement comme étant gérés par le bean entité EJB. Voici les participants à Composite Entity Bean.
Composite Entity- C'est le bean entité primaire. Il peut être à gros grains ou contenir un objet à gros grains à utiliser à des fins de persistance.
Coarse-Grained Object- Cet objet contient des objets dépendants. Il a son propre cycle de vie et gère également le cycle de vie des objets dépendants.
Dependent Object - Un objet dépendant est un objet qui dépend d'un objet à grain grossier pour son cycle de vie de persistance.
Strategies - Stratégies représente la manière de mettre en œuvre une entité composite.
Le modèle d'objet d'accès aux données ou le modèle DAO est utilisé pour séparer les données de bas niveau accédant à l'API ou aux opérations des services métier de haut niveau. Voici les participants au modèle d'objet d'accès aux données.
Data Access Object Interface - Cette interface définit les opérations standard à effectuer sur un ou plusieurs objets du modèle.
Data Access Object concrete class- Cette classe implémente l'interface ci-dessus. Cette classe est chargée d'obtenir des données à partir d'une source de données qui peut être database / xml ou tout autre mécanisme de stockage.
Model Object or Value Object - Cet objet est un simple POJO contenant des méthodes get / set pour stocker les données récupérées à l'aide de la classe DAO.
Le modèle de conception de contrôleur frontal est utilisé pour fournir un mécanisme de gestion des demandes centralisé afin que toutes les demandes soient traitées par un seul gestionnaire. Ce gestionnaire peut effectuer l'authentification / l'autorisation / la journalisation ou le suivi de la demande, puis transmettre les demandes aux gestionnaires correspondants. Voici les entités de ce type de modèle de conception.
Front Controller - Gestionnaire unique pour tous les types de requêtes venant de l'application (soit basée sur le Web / basée sur le bureau).
Dispatcher - Le contrôleur frontal peut utiliser un objet répartiteur qui peut envoyer la demande au gestionnaire spécifique correspondant.
View - Les vues sont l'objet pour lequel les demandes sont faites.
Le modèle de conception de filtre d'interception est utilisé lorsque nous voulons effectuer un pré-traitement / post-traitement avec une demande ou une réponse de l'application. Les filtres sont définis et appliqués sur la demande avant de la transmettre à l'application cible réelle. Les filtres peuvent effectuer l'authentification / l'autorisation / la journalisation ou le suivi de la demande, puis transmettre les demandes aux gestionnaires correspondants.
Voici les entités de ce type de modèle de conception.
Filter - Filtre qui effectuera certaines tâches avant ou après l'exécution de la requête par le gestionnaire de requête.
Filter Chain - La chaîne de filtres comporte plusieurs filtres et aide à les exécuter dans l'ordre défini sur la cible.
Target - L'objet cible est le gestionnaire de requêtes.
Filter Manager - Filter Manager gère les filtres et la chaîne de filtres.
Client - Le client est l'objet qui envoie la demande à l'objet cible.
Le modèle de conception de localisateur de services est utilisé lorsque nous voulons localiser divers services à l'aide de la recherche JNDI. Compte tenu du coût élevé de recherche de JNDI pour un service, le modèle de localisateur de service utilise la technique de mise en cache. Pour la première fois qu'un service est requis, Service Locator recherche dans JNDI et met en cache l'objet de service. Une recherche supplémentaire ou le même service via Service Locator est effectué dans son cache, ce qui améliore considérablement les performances de l'application.
Le modèle d'objet de transfert est utilisé lorsque nous voulons transmettre des données avec plusieurs attributs en une seule fois du client au serveur. L'objet de transfert est également appelé objet de valeur. Transfer Object est une simple classe POJO ayant des méthodes getter / setter et est sérialisable afin de pouvoir être transférée sur le réseau. Il n'a aucun comportement. La classe affaires côté serveur récupère normalement les données de la base de données et remplit le POJO et l'envoie au client ou le transmet par valeur. Pour le client, l'objet de transfert est en lecture seule. Le client peut créer son propre objet de transfert et le transmettre au serveur pour mettre à jour les valeurs de la base de données en une seule fois. Voici les entités de ce type de modèle de conception.
Business Object - Business Service remplit l'objet de transfert avec des données.
Transfer Object - POJO simple ayant des méthodes pour définir / obtenir des attributs uniquement.
Client - Le client demande ou envoie l'objet de transfert à Business Object.