Chaque objet peut être classifié en deux catégories:objets individuels et objets composés qui sont composés à leur tour d’objets individuels ou composés.

Le design pattern Composite est utile pour concevoir une hierarchie entres ces objets et pour traiter les objets individuels et composés d’une manière transparente.Et il est très utilisé pour représenter les données récursives.

Exemple

Le pattern Iterator permet à un objet client d’accéder au contenu d’un objet conteneur( tableau, list , Hastable…) séquentiellement sans avoir à connaitre la structure interne de cet aggrégat.
Pour accomplir cela, Ce pattern suggère que l’objet conteneur doit fournir une interface public sous la forme d’un objet ITERATOR pour les différents objets clients pour qu’ils accèdent à son contenu.
Cet iterator doit fournir les méthodes publiques nécessaires pour permettre aux objets clients le parcours de la liste des objets.

Exemple

En général le detail de la construction d’un objet comme l’instanciation et l’initialisaiton de ces composants est conservé à l’intérieur de l’objet dans son constructeur.

Cette approche convient aussi longtems que la construction de l’objet en question est simple:le processus de construction de l’objet est bien défini et produit la même représentation de l’objet.

Cette approche ne convient plus si l’objet crée est complexe parce que tout le traitement de construction sera maintenu à l’intérieur de l’objet ce qui peut devenir encombrant et moins modulaire.

Par la suite , Apporter des modifications ou bien ajouter des nouveaux processus de construction d’objet exige la modification du code.

En utilisant le pattern Builder , la logique de la construction de l’objet est déplacé à une classe distincte Appelé « Builder Class ». Par la suite , Ce pattern introduit un autre niveau de séparation pour éviter que les méthodes de Builder d’être invoqué directement et cela en utilisant le « Director » qui est responsable de l’appel des différents méthodes du builder requis pour la construction de l’objet.

Exemple

Description

Ce pattern est utilisé quand le système a besoin de nouvelles instances, mais il ignore de quelle classe, or il dispose d’instance de la classe désirée.

Ce pattern peut aussi être utilisé quand le système a besoin de créer plusieurs objets identiques et le processus de création de classe à travers les classes factories où bien d’autres facteurs peut revenir plus cher qu’une simple copie

Alors le principe est simple:
-On crée un objet et on le désigne comme prototype.
-On crée les autres objets en faisant des copies simples du prototype.

Exemple

Le pattern Abstract Factory met en place une classe fournissant l’interface de fabrication d’une famille d’objets.

Ce pattern est utile quand le système utilise des objets regroupés en famille. Et si ,Selon certains facteurs, le système utilise des objets d’une famille ou d’une autre.

Exemple

Dans une hiérarchie de classes, Tous les sous-classes héritent des méthodes implémentées dans la classe mère. Ces sous-classes pourraient redéfinir ces méthode pour les adapter et offrir des fonctionnalités différentes.

Quand on connaît exactement la fonctionnalité qu’on a besoin, on pourrait instancié directement la bonne classe dans la hierarchie des classes qui offre cette fonctionnalité.

Or,parfois on ne peut pas connaître auparavant quelle classe dans la hierarchie on aura besoin.
Le choix pourrait dépendre de plusieurs facteurs comme:
-L’état d’execution de l’application.
-Paramètres de configuration de l’application.
-prévision d’éventuel amélioration et évolution de l’application.

Dans ce cas, La conception normale consiste à implémenter un traitement de sélection de la bonne classe à instancier de la hierarchie de classe.

Ce type de design a plusieurs inconveniants:
-Chaque classe cliente qui va utiliser ce service est obligée d’implémenter le traitement de selection de la classe, et par conséquant nous aurons un couplage fort entre les objets de l’application et le service offert par cette hierachie de classe
-Si jamais le traitement de selection de la classe change, tous les objets de l’application qui utilise la hiérarchie doivent changer.
-Traitement lourd si jamais l’instanciation des sous-classes se fait différement et les facteurs de selection de la classe est plus compliqués.
-Les objets de l’application doivent connaître les services offerts par la hierarchie des classes.

Solution

Dans ce cas , le pattern Factory Method recommande l’encapsulation du traitement de la selection de la bonne classe dans une méthode d’ou le nom « Factory method » qui aura comme rôle :
-Selection de la classe appropriée à instanciée en se basant sur les facteurs influents.
-Instanciation la classe en question et la retourner comme instance de la classe mère.

En implémentant le Factory Method Pattern on bénéficie de plusieurs avantages:
-L’application pourra utiliser la « Factory method » pour accéder à la bonne instance de classe et cela élimine le faite que les objets d’application implémentent le traitement de selection de classe.
-« Factory method » cache toute la complexité du choix de la bonne classe à instancier.
-Puisque la « Factory method » retourne l’instance de la classe mère alors les objets d’application n’ont pas besoin de connaître l’exsistance de la hiérarchie de classe.

Exemple1

Exemple2

Le Pattern singleton est facile à comprendre. Il nous aide à implémenter une classe pour laquel on a besoin q’une seule instance pendant la durée de vie de l’application comme : Connexion à une base de données,….

On pourrait implémenter facilement ce principe en ayant une variable globale pour maintenir une instance unique. Et tous les objets clients pourront l’utiliser. Mais cette approche ne pourra pas prévenir la création d’autres instances sauf que si tous les objets clients contrôleront eux même ses nombres d’instances.

Mais cela transgresse le principe de responsabilité des classe, puisque les objets clients n’ont pas à connaître le détails de création de la classe en question, puisque,c’est elle qui doit s’en charger.

Solution

Une classe qui maintient elle même son instance unique est appelée une classe singleton et le pattern Singleton nous aide à l’implémenter

Exemple

Dans un système orienté objet, une classe donnée pourra dépendre des services fournis par d’autres classes.
L’approche normale consiste à implémenter cette dépendance de la manière suivante:

La classe « Client » requiert un service de la classe « Fournisseur de service ».
Cette approche est bonne si seulement on assume que ce type de service est toujours fourni par la même classe.
Mais cette méthode ne convient plus quand plusieurs classes offre le même type de service.

Solution

En Appliquant le design pattern « interface », les services communs offerts par les différentes classes peuvent être isolés et déclarés abstraits en tant qu’interface. Et chacune des classes qui fournissent ce type de service implémente cette interface.
Cela permet à la classe « Client » l’utilisation du service requis avec un minimum d’impact et d’une manière complètement transparente. Et par conséquent, elle n’a pas besoin d’être modifiée quand une nouvelle classe « fournisseur de service » est désignée.

Exemple

Dans une application les objets utilisent différents types de données variables et constants.
Le pattern Constant Data Manager sert pour la conception d’un espace de stockage efficace pour les données constantes utilisées par différents objets dans une application.
En général, une application manipule différent sorte de données constantes comme: Nom fichier,
Label des butons , Les Codes et les messages d’erreur….

Ce pattern recommande que les données constantes doivent être garder dans des objets séparés. Ce type de séparation facilite la maintenance du référentiel centralisé des données constantes.

Exemple

Comment concevoir une classe avec un comportement variable?

Solution

Exemple