Cyrille Giquello

Outils pour utilisateurs

Outils du site

Vous êtes ici : accueil » informatique » design_pattern
Piste :
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
informatique:design_pattern [05/09/2010 17:25] – cyrilleinformatique:design_pattern [03/03/2023 14:56] (Version actuelle) – [Documentation] SOLID principles - Increased maintainability, Increased testability, Increased flexibility, Better code organization 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://smeric.developpez.com/java/uml/|Tutoriel UML et Design Pattern]] sur [[http://smeric.developpez.com|smeric.developpez.com]] +  * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/|Design Patterns du Gang of Four appliqués à Java]] 
 +  * 
 Sources : Sources :
   * [[http://fr.wikipedia.org/wiki/Design_pattern|Wikipedia (fr)]] et [[http://en.wikipedia.org/wiki/Design_pattern_(computer_science)|Wikpedia (en)]]   * [[http://fr.wikipedia.org/wiki/Design_pattern|Wikipedia (fr)]] et [[http://en.wikipedia.org/wiki/Design_pattern_(computer_science)|Wikpedia (en)]]
Ligne 16: Ligne 16:
   * (en) http://davidhayden.com/blog/dave/category/22.aspx?Show=All   * (en) http://davidhayden.com/blog/dave/category/22.aspx?Show=All
   * [[http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns.html|Les design patterns]] sur le site [[http://best-practice-software-engineering.ifs.tuwien.ac.at|best-practice-software-engineering.ifs.tuwien.ac.at]]   * [[http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns.html|Les design patterns]] sur le site [[http://best-practice-software-engineering.ifs.tuwien.ac.at|best-practice-software-engineering.ifs.tuwien.ac.at]]
 +  * [[http://smeric.developpez.com/java/uml/|Tutoriel UML et Design Pattern]] sur [[http://smeric.developpez.com|smeric.developpez.com]]
 +
 +
 +[[https://medium.com/@eloufirhatim/solid-principles-in-laravel-1418be178346|SOLID principles]]
 +  * Increased maintainability, Increased testability, Increased flexibility, Better code organization
 +  * Single Responsibility Principle (SRP)
 +    * The SRP states that a class should have only one reason to change. In other words, a class should only have one responsibility and be focused on doing one thing well.
 +  * Open/Closed Principle (OCP)
 +    * The OCP states that a class should be open for extension, but closed for modification.
 +  * Liskov Substitution Principle (LSP)
 +    * The LSP states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program. In other words, a subclass should be a substitute for its superclass.
 +  * Interface Segregation Principle (ISP)
 +    * The ISP states that classes should not be forced to implement interfaces they do not use. This principle can be applied by creating smaller, more focused interfaces that define specific tasks
 +  * Dependency Inversion Principle (DIP)
 +    * The DIP states that high-level modules should not depend on low-level modules, but both should depend on abstractions. This principle helps to reduce the coupling between modules
  
  
Ligne 27: Ligne 42:
     * 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 179: Ligne 194:
  
 From a layering point of view, the presenter class might be considered as belonging to the application layer in a multilayered architecture system with common layers but it can also be seen as a presenter layer of its own between the application layer and the user interface layer. From a layering point of view, the presenter class might be considered as belonging to the application layer in a multilayered architecture system with common layers but it can also be seen as a presenter layer of its own between the application layer and the user interface layer.
- 
-===== Distribution Patterns ===== 
-==== Remote Facade ==== 
-==== Data Transfer Object ==== 
- 
-L'un des premiers gourous à avoir introduit le Design Pattern DTO (ou Value Object) est Martin Fowler. Ces derniers temps, avec l'essor des outils de mapping o/r il devient de plus en plus aisé de transférer un modèle objet “pur” sur la couche cliente. Et la distribution de la couche de service, autre argument en faveur des DTO, est de moins en moins privilégiée dans les architectures n-tiers modernes. 
- 
-  * http://petitteckel.wordpress.com/2007/11/01/le-modele-de-conception-dto/ 
-  * [[http://martinfowler.com/bliki/LocalDTO.html|LocalDTO]]: dans cet article, Martin Fowler répond donc à Jon Tirsen qui titrait sur son blog “Data Transfer Objects makes me sick! 
- 
  
  
Ligne 216: Ligne 221:
  
 {{: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 293: Ligne 314:
   * http://www.dofactory.com/Patterns/PatternFacade.aspx   * http://www.dofactory.com/Patterns/PatternFacade.aspx
  
-==== Interface / Adapteur ====+==== Adapter / Wrapper ====
  
 Synonymes: Encapsulateur, Empaquetage. Synonymes: Encapsulateur, Empaquetage.
  
-An interface defines the signature operations of an entity, it also sets the communication boundary between two entities, in this case two pieces of software. It generally refers to an abstraction that an asset provides of itself to the outside.+L'Adapteur permet d'isoler l'adaptation d'un sous-système. 
  
-Use an interface when: +  * Convertir l'interface d'une classe dans une autre interface comprise par la partie cliente. 
-  * you want to specify how classes exchange messages. I.e., every time, when a class should be reused, or used outside a specific context (package) declare the communication interface as an Interface type +  * Permettre à des classes de fonctionner ensemble, ce qui n'aurait pas été possible sinon (à cause de leurs interfaces incompatibles).
-  * you have to switch the implementation of a module during run-time +
-  * at design-time you don't yet know which implementation you will use at compile-time +
- +
-Related Patterns: +
-  * Many other patterns use interfaces, a lot of them depend on the interface pattern. +
-  * It is possible to combine the interface pattern with virtually any other pattern to make them more flexible.+
  
 Pour des raisons de conformité à une norme, pour ne pas dépendre d'une implémentation, pour permettre l'évolution de votre projet, il arrive que vous ayez besoin de vous reposer sur une interface ou une API qui n'est pas précisément celle qui vous est fournie. Ce design pattern vous propose de pallier cette problématique. Pour des raisons de conformité à une norme, pour ne pas dépendre d'une implémentation, pour permettre l'évolution de votre projet, il arrive que vous ayez besoin de vous reposer sur une interface ou une API qui n'est pas précisément celle qui vous est fournie. Ce design pattern vous propose de pallier cette problématique.
Ligne 312: Ligne 327:
 {{:informatique:design_pattern:adaptateur.png|}} {{:informatique:design_pattern:adaptateur.png|}}
  
-Such a construction of using an interface is often combined with the [[#Factory|Factory-Pattern]] to retrieve the Implementation of the interface.+Adaptateur avec héritage: \\ 
 +{{:informatique:design_pattern:designpatternstructuraladaptatorheritage.png|design pattern structural adaptator heritage}} 
 + 
 +Adaptateur avec 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 335: Ligne 358:
  
 ==== Value Object ==== ==== Value Object ====
-==== Money ==== + 
-==== Special Case ====+ 
 + 
 ==== Plugin ==== ==== Plugin ====
  
Ligne 402: Ligne 427:
 ===== Plus de pattern ===== ===== Plus de pattern =====
  
 +
 +===== Distribution Patterns =====
 +==== Remote Facade ====
 +==== Data Transfer Object ====
 +
 +L'un des premiers gourous à avoir introduit le Design Pattern DTO (ou Value Object) est Martin Fowler. Ces derniers temps, avec l'essor des outils de mapping o/r il devient de plus en plus aisé de transférer un modèle objet “pur” sur la couche cliente. Et la distribution de la couche de service, autre argument en faveur des DTO, est de moins en moins privilégiée dans les architectures n-tiers modernes.
 +
 +  * http://petitteckel.wordpress.com/2007/11/01/le-modele-de-conception-dto/
 +  * [[http://martinfowler.com/bliki/LocalDTO.html|LocalDTO]]: dans cet article, Martin Fowler répond donc à Jon Tirsen qui titrait sur son blog “Data Transfer Objects makes me sick!
  
  
informatique/design_pattern.1283700306.txt.gz · Dernière modification : 19/05/2012 00:16 (modification externe)
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