informatique:design_pattern
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
informatique:design_pattern [05/09/2010 17:24] – cyrille | informatique: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:// | + | * <del>[[http:// |
- | * [[http://smeric.developpez.com/ | + | * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/ |
+ | | ||
Sources : | Sources : | ||
* [[http:// | * [[http:// | ||
Ligne 16: | Ligne 16: | ||
* (en) http:// | * (en) http:// | ||
* [[http:// | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | |||
+ | [[https:// | ||
+ | * Increased maintainability, | ||
+ | * 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, | * Architectural Patterns express a fundamental structural organization or schema for software systems. They provide a set of predefined subsystems, specify their responsibilities, | ||
- | * Model View Controller (MVC) | + | * [[# |
- | * Dependency Injection | + | * [[# |
* Structural Design Patterns are concerned with how classes and objects are composed together to form larger structures. [GoF, " | * Structural Design Patterns are concerned with how classes and objects are composed together to form larger structures. [GoF, " | ||
- | * Facade | + | * [[#facade|Facade]] |
* Decorator | * Decorator | ||
* Proxy | * Proxy | ||
- | * Data Access Object | + | * Data Access Object |
- | * Transfer Object | + | * [[# |
* Creational Design Patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. [GoF, " | * Creational Design Patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. [GoF, " | ||
- | * Factory Method | + | * [[# |
- | * Abstract Factory | + | * [[# |
* Objectpool | * Objectpool | ||
- | * Singleton | + | * [[# |
* Behavioral Design Patterns are concerned with algorithms and the assignment of responsibilities between objects. [GoF, " | * Behavioral Design Patterns are concerned with algorithms and the assignment of responsibilities between objects. [GoF, " | ||
* Iterator | * Iterator | ||
- | * Observer | + | * [[# |
* Event Listener | * Event Listener | ||
- | * Strategy | + | * [[# |
The diagram below shows the relationships between the patterns described in [[http:// | The diagram below shows the relationships between the patterns described in [[http:// | ||
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' | ||
- | |||
- | * http:// | ||
- | * [[http:// | ||
- | |||
- | |||
- | |||
- | ===== Session State Patterns ===== | ||
- | ==== Client Session State ==== | ||
- | ==== Server Session State ==== | ||
- | ==== Database Session State ==== | ||
Ligne 222: | Ligne 221: | ||
{{: | {{: | ||
+ | |||
+ | |||
+ | ==== Singleton ==== | ||
+ | |||
+ | * Restreindre le nombre d' | ||
+ | * 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' | ||
+ | |||
+ | 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:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
====Strategy ==== | ====Strategy ==== | ||
Ligne 299: | Ligne 314: | ||
* http:// | * http:// | ||
- | ==== Interface | + | ==== Adapter |
Synonymes: Encapsulateur, | Synonymes: Encapsulateur, | ||
- | 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' |
- | Use an interface when: | + | |
- | | + | * Permettre à des classes de fonctionner ensemble, ce qui n' |
- | * 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 | + | |
- | * It is possible | + | |
Pour des raisons de conformité à une norme, pour ne pas dépendre d'une implémentation, | Pour des raisons de conformité à une norme, pour ne pas dépendre d'une implémentation, | ||
Ligne 318: | Ligne 327: | ||
{{: | {{: | ||
- | 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: \\ |
+ | {{: | ||
+ | |||
+ | Adaptateur avec composition: | ||
+ | {{: | ||
+ | |||
+ | Voir: | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
==== Gateway ==== | ==== Gateway ==== | ||
Ligne 341: | Ligne 358: | ||
==== Value Object ==== | ==== Value Object ==== | ||
- | ==== Money ==== | + | |
- | ==== Special Case ==== | + | |
+ | |||
==== Plugin ==== | ==== Plugin ==== | ||
Ligne 407: | Ligne 426: | ||
===== 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' | ||
+ | |||
+ | * http:// | ||
+ | * [[http:// | ||
+ | |||
informatique/design_pattern.txt · Dernière modification : 03/03/2023 14:56 de cyrille