Design Patterns
Mes Notes & Resume Complet
Creation Structurel Comportemental
PATTERNS COUVERTS
Factory Method Builder
Abstract Factory Adapter
Singleton Decorator
Prototype Observer
Programmation Orientee Objet - Java / OOP
Patterns de Creation
Gerer la creation des objets de maniere flexible et reutilisable
Factory Method
Design Pattern
Principe : Utiliser le polymorphisme pour deleguer la creation d'objets a des sous-classes, sans repeter
new Classe() partout dans le code.
Le polymorphisme en Java — 2 types :
Statique (compile-time) — Overloading : meme nom de methode, parametres differents
Dynamique (runtime) — Overriding : redefinir une methode dans la sous-classe
Schema :
Client
|
Creator (interface / abstract class)
| creerProduit() <-- methode factory
|
ConcreteCreator --> ConcreteProduct
Quand l'utiliser : quand on ne veut pas dependre d'une classe concrete et eviter de repeter new
Classe() partout dans le projet.
Abstract Factory
Design Pattern
Principe : Creer une famille d'objets lies sans preciser leurs classes concretes. Pour ajouter un nouveau
produit (ex: une voiture avec nouvelles specifications), on cree une nouvelle classe qui implemente
l'interface.
Factory Method Abstract Factory
• Cree UN seul produit • Cree une FAMILLE
• 1 interface produit • Plusieurs interfaces
• Sous-classe decide • Factory coordonne
• Plus simple • Plus puissant
Singleton
Design Pattern
Principe : Garantir qu'une classe n'a qu'une seule instance en memoire. Exemple : une classe Login ou
connexion BD doit toujours utiliser la meme zone memoire.
Fonctionnement :
En haut de la classe : private static Classe instance = new Classe()
Constructeur private — personne ne peut faire new Classe()
Methode getInstance() retourne toujours la meme instance
●●●
// Singleton — une seule instance garantie
public class LoginManager {
private static LoginManager instance = new LoginManager();
private LoginManager() {} // constructeur prive
public static LoginManager getInstance() {
return instance;
}
}
// Utilisation — toujours le meme objet
LoginManager lm = [Link]();
Singleton Prototype
• Une seule instance • Plusieurs copies
• Empeche duplication • Facilite duplication
• Meme objet partout • clone() = nouvel objet
• Ex: login, config • Ex: templates
Prototype
Design Pattern
Principe : Creer de nouveaux objets en clonant un objet existant. Chaque appel a clone() retourne une
copie independante — pas la meme reference memoire.
Quand utiliser Prototype :
Quand la creation d'objet est couteuse (ex: requete BD)
Quand tu veux eviter beaucoup de new
Quand tu veux cloner des configurations existantes
●●●
// clone() retourne une COPIE independante
User u1 = new User("Sofia", "sofia@[Link]");
User u2 = (User) [Link]();
// u2 est une copie de u1
// Modifier u2 ne change PAS u1 !
Builder
Design Pattern
Principe : Construire un objet complexe etape par etape pour eviter les erreurs dans les constructeurs avec
beaucoup de parametres. La classe interne Builder simplifie l'initialisation.
●●●
public class User {
private String username, email, password, phone, address;
private User(Builder b) {
[Link] = [Link];
[Link] = [Link]; // ... etc
}
public static class Builder {
private String username, email, password, phone, address;
public Builder username(String v) { [Link]=v; return this; }
public Builder email(String v) { [Link]=v; return this; }
public Builder password(String v) { [Link]=v; return this; }
public Builder phone(String v) { [Link]=v; return this; }
public Builder address(String v) { [Link]=v; return this; }
public User build() { return new User(this); }
}
}
// Utilisation — fluide et lisible
User user = new [Link]()
.username("sofia")
.email("sofia@[Link]")
.password("123456")
.phone("0600000000")
.address("Marrakech")
.build();
Chaque methode du Builder retourne this => permet le chainage fluide.
Patterns Structurels
Composer les classes et objets pour former de plus grandes structures
Adapter
Design Pattern
Principe : Convertir l'interface d'une classe en une autre interface attendue par le client. On utilise une
classe intermediaire (Adapter) pour faire la traduction entre deux interfaces incompatibles.
Schema :
Client
|
v
Target Interface (ce que le client attend)
|
v
Adapter (fait la traduction)
|
v
Adaptee (classe existante incompatible)
Analogie : Comme un adaptateur de prise electrique — brancher un appareil europeen sur une prise americaine
grace a l'adaptateur.
Decorator
Design Pattern
Principe : Ajouter des fonctionnalites a un objet sans modifier sa classe et sans creer beaucoup de
sous-classes. On cree une seule classe Decorator qui enveloppe l'objet original.
Schema :
Component (interface)
|________________________
| |
ConcreteComponent Decorator (wraps Component)
(objet de base) |
ConcreteDecorator
(ajoute du comportement)
Avantage cle : Pas besoin de sous-classe pour chaque combinaison. On empile les decorateurs.
Exemple : Coffee + Milk + Sugar => on decore l'objet Coffee avec Milk, puis avec Sugar.
Patterns Comportementaux
Gerer la communication et les responsabilites entre objets
Observer
Design Pattern
Principe : Notifier automatiquement plusieurs objets (Observers) lorsqu'un objet (Subject) change d'etat.
Relation 1 -> N.
Schema :
Subject (Observable)
- liste d'observers
- attach(observer)
- detach(observer)
- notifyAll() <-- appelle update() de chaque observer
|
|--- Observer 1 --> update()
|--- Observer 2 --> update()
'--- Observer 3 --> update()
Quand utiliser Observer :
Systeme d'evenements (clic bouton => plusieurs reactions)
Notifications (stock change => alerter plusieurs clients)
MVC : le modele notifie la vue automatiquement
●●●
// Subject notifie tous les observers automatiquement
public class StockMarket {
private List<Observer> observers = new ArrayList<>();
private double price;
public void addObserver(Observer o) { [Link](o); }
public void setPrice(double price) {
[Link] = price;
notifyObservers();
}
private void notifyObservers() {
for (Observer o : observers) [Link](price);
}
}
Recapitulatif — Tous les Patterns
Pattern Categorie Probleme resolu Mot-cle
Factory Method Creation Instanciation repetee Polymorphisme
Abstract Factory Creation Famille d'objets Interface commune
Singleton Creation Une seule instance getInstance()
Prototype Creation Copie d'objet couteux clone()
Builder Creation Init complexe Chainage fluide
Adapter Structurel Interfaces incompatibles Classe intermediaire
Decorator Structurel Ajouter comportement Wrapper
Observer Comportemental Notifications auto Subject / Observer
Conseil : Les Design Patterns ne sont pas des regles rigides — ce sont des solutions eprouvees a des
problemes recurrents. Comprendre quand les utiliser est plus important que de memoriser leur code.