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