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édenteDernière révisionLes deux révisions suivantes | ||
informatique:design_pattern [05/09/2010 17:43] – cyrille | informatique:design_pattern [18/01/2016 13:21] – [Documentation] cyrille | ||
---|---|---|---|
Ligne 6: | Ligne 6: | ||
Commencer par lire: | Commencer par lire: | ||
- | * [[http:// | + | * <del>[[http:// |
* [[http:// | * [[http:// | ||
* | * | ||
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, | * 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 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' | 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... | + | Le singleton est souvent vu comme un anti-pattern |
- | + | ||
- | http:// | + | |
- | + | ||
- | The singleton pattern was described in the GoF Design Patterns | + | |
- | + | ||
- | 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:// | * [[http:// | ||
* [[http:// | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
====Strategy ==== | ====Strategy ==== |
informatique/design_pattern.txt · Dernière modification : 03/03/2023 14:56 de cyrille