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:43] 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 216: Ligne 216:
 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.  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... +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).
- +
-http://www.picocontainer.org/singleton-antipattern.html +
- +
-The singleton pattern was described in the GoF Design Patterns  book. Because of its static nature and global availability, it allows component writers to obscurely reference other components. Overuse makes for bad solutions. Overuse at the enterprise level, it makes for very bad solutions. +
- +
-We claim that the GoF Singleton pattern is, in fact, quite often an anti-pattern. The downside of the singleton is that there are many transitive dependancies that are not easy to spot. Singletons cannot easily be replaced with Mock Objects for the sake of easy unit testing.+
  
 Voir: Voir:
   * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/?page=page_2#LIV-E|Le singleton par Régis POUILLER]]   * [[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://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 ====
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