Outils pour utilisateurs

Outils du site


informatique:design_pattern

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
Dernière révisionLes deux révisions suivantes
informatique:design_pattern [05/09/2010 17:32] cyrilleinformatique:design_pattern [18/01/2016 13:21] – [Documentation] cyrille
Ligne 6: Ligne 6:
  
 Commencer par lire: Commencer par lire:
-  * [[http://www.crossbowlabs.com/dossiers/principes-avances-oo|Principes avancés de conception objet]].+  * <del>[[http://www.crossbowlabs.com/dossiers/principes-avances-oo|Principes avancés de conception objet]]</del>.
   * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/|Design Patterns du Gang of Four appliqués à Java]]   * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/|Design Patterns du Gang of Four appliqués à Java]]
   *    * 
Ligne 28: Ligne 28:
     * Delegation     * Delegation
   * Architectural Patterns express a fundamental structural organization or schema for software systems. They provide a set of predefined subsystems, specify their responsibilities, and include rules and guidelines for organizing the relationships between them.   * Architectural Patterns express a fundamental structural organization or schema for software systems. They provide a set of predefined subsystems, specify their responsibilities, and include rules and guidelines for organizing the relationships between them.
-    * Model View Controller (MVC) +    * [[#model_view_controller|Model View Controller (MVC)]] 
-    * Dependency Injection +    * [[#dependency_injection|Dependency Injection]] 
   * Structural Design Patterns are concerned with how classes and objects are composed together to form larger structures. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]   * Structural Design Patterns are concerned with how classes and objects are composed together to form larger structures. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]
-    * Facade+    * [[#facade|Facade]]
     * Decorator     * Decorator
     * Proxy     * Proxy
-    * Data Access Object +    * Data Access Object (DAO) 
-    * Transfer Object+    * [[#data_transfer_object|Data Transfer Object (DTO)]]
   * Creational Design Patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]   * Creational Design Patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]
-    * Factory Method +    * [[#factoryfabrique|Factory Method]] 
-    * Abstract Factory+    * [[#factoryfabrique|Abstract Factory]]
     * Objectpool     * Objectpool
-    * Singleton+    * [[#singleton|Singleton]]
   * Behavioral Design Patterns are concerned with algorithms and the assignment of responsibilities between objects. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]   * Behavioral Design Patterns are concerned with algorithms and the assignment of responsibilities between objects. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]
     * Iterator     * Iterator
-    * Observer+    * [[#observer|Observer]]
     * Event Listener     * Event Listener
-    * Strategy+    * [[#strategy|Strategy]]
  
 The diagram below shows the relationships between the patterns described in [[http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns.html|this documentation]], the notation is according to Zimmer's classifications and relationships. [Zimmer, Walter (1995), "Relationships between Design Patterns", from "Pattern Languages of Program Design", Addison-Wesley.]  There are three types of relationships in this diagram: uses (pattern us used by), combine (pattern can be used by), and similar (patterns are similar in their design). The diagram below shows the relationships between the patterns described in [[http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns.html|this documentation]], the notation is according to Zimmer's classifications and relationships. [Zimmer, Walter (1995), "Relationships between Design Patterns", from "Pattern Languages of Program Design", Addison-Wesley.]  There are three types of relationships in this diagram: uses (pattern us used by), combine (pattern can be used by), and similar (patterns are similar in their design).
Ligne 207: Ligne 207:
  
 {{:informatique:design_pattern:designpatterncreationalfactorymethod.png|}} {{:informatique:design_pattern:designpatterncreationalfactorymethod.png|}}
 +
 +
 +==== Singleton ====
 +
 +  * Restreindre le nombre d'instances d'une classe à une et une seule.
 +  * Fournir une méthode pour accéder à cette instance unique.
 +
 +Singleton doit restreindre le nombre de ses propres instances à une et une seule. Son constructeur est privé : cela empêche les autres classes de l'instancier. La classe fournit la méthode statique getInstance() qui permet d'obtenir l'instance unique. 
 +
 +Le singleton est souvent vu comme un anti-pattern car il amène des dépendances un peu partout et qu'il n'est pas facilement remplaçable pas des objets bidons (Mock object).
 +
 +Voir:
 +  * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/?page=page_2#LIV-E|Le singleton par Régis POUILLER]]
 +  * [[http://smeric.developpez.com/java/uml/singleton/|Le singleton par Sébastien MERIC]]
 +  * [[http://www.picocontainer.org/singleton-antipattern.html|Le singleton par le projet Pico Container]] qui le voit comme un anti-pattern]]
 +  * [[http://christophej.developpez.com/tutoriel/java/singleton/multithread/|Le Singleton en environnement Multithread]] par Christophe Jollivet.
  
 ====Strategy ==== ====Strategy ====
Ligne 287: Ligne 303:
  
 Synonymes: Encapsulateur, Empaquetage. Synonymes: Encapsulateur, Empaquetage.
 +
 +L'Adapteur permet d'isoler l'adaptation d'un sous-système. 
  
   * Convertir l'interface d'une classe dans une autre interface comprise par la partie cliente.   * Convertir l'interface d'une classe dans une autre interface comprise par la partie cliente.
Ligne 295: Ligne 313:
 {{:informatique:design_pattern:adaptateur.png|}} {{:informatique:design_pattern:adaptateur.png|}}
  
-Adaptateur avec héritage : +Adaptateur avec héritage: \\
 {{:informatique:design_pattern:designpatternstructuraladaptatorheritage.png|design pattern structural adaptator heritage}} {{:informatique:design_pattern:designpatternstructuraladaptatorheritage.png|design pattern structural adaptator heritage}}
  
-Adaptateur avec composition : +Adaptateur avec composition: \\
 {{:informatique:design_pattern:designpatternstructuraladaptatorcomposition.png|design pattern structural adaptator composition}} {{:informatique:design_pattern:designpatternstructuraladaptatorcomposition.png|design pattern structural adaptator composition}}
  
 +Voir:
 +  * [[http://smeric.developpez.com/java/uml/adaptateur/|L'adaptateur par Sébastien MERIC]]
 +  * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/?page=page_3#LV-A|L'adapteur par Régis POUILLER]]
  
 ==== Gateway ==== ==== Gateway ====
Ligne 323: Ligne 344:
  
 ==== Value Object ==== ==== Value Object ====
-==== Money ==== + 
-==== Special Case ====+ 
 + 
 ==== Plugin ==== ==== Plugin ====
  
informatique/design_pattern.txt · Dernière modification : 03/03/2023 14:56 de cyrille

Sauf mention contraire, le contenu de ce wiki est placé sous les termes de la licence suivante : CC0 1.0 Universal
CC0 1.0 Universal Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki