Les Design Patterns sont des solutions éprouvées aux problèmes courants que les développeurs rencontrent lors de la création d’applications logicielles. Ils fournissent un moyen éprouvé de résoudre des problèmes récurrents de conception, en utilisant une approche standardisée pour structurer le code.
Les Design Patterns ne sont pas une solution à tous les problèmes de conception, mais ils peuvent être très utiles dans de nombreux contextes, en permettant aux développeurs de résoudre rapidement et facilement les problèmes courants et de créer des applications logicielles plus robustes et maintenables. Dans cet article, nous allons explorer certains des Design Patterns les plus couramment utilisés en PHP, ainsi que leurs applications pratiques (dans d’autres articles).
Les Design Patterns en PHP s’adresse aux concepteurs et aux développeurs pratiquant régulièrement la programmation orientée objet pour réaliser des applications s’appuyant sur des solutions robustes.
Nous allons parler de quelques design patterns parmi les 23 existants. En gros telle décrit dans le livre du Ganf of Four
- Les design patterns de création ont pour objectif l’abstraction des mécanismes de construction d’objets. Les mécanismes d’instanciation des classes concrètes sont encapsulés au sein des design patterns. En cas de modification de l’ensemble des classes concrètes à instancier, les modifications à apporter dans le système seront peu nombreuses, voire inexistantes.
- Les design patterns structurels ont pour but d’abstraire l’interface d’un objet ou d’un ensemble d’objets de son implémentation. Dans le cas d’un ensemble d’objets, l’objectif est aussi d’abstraire l’interface des relations d’héritage ou de composition présentes dans l’ensemble.
- Les design patterns de comportement fournissent des solutions pour structurer les données et les objets ainsi qu’organiser les interactions en distribuant les traitements et les algorithmes entre les objets.
L’étude des design patterns nous donne l’occasion de revenir sur certains concepts fondamentaux de la programmation orientée objet (POO)
- l’héritage ;
- l’encapsulation ;
- l’abstraction ;
- le polymorphisme.
Voici plus de détail
Il ne faut pas oublier non plus les principes SOLID. Ces cinq principes sont extraits d’un article paru en 2000 et écrit par l’informaticien américain Robert C. Martin, surnommé affectueusement « Uncle Bob » par la communauté internationale des développeurs.
- Le principe de responsabilité unique : une classe ne doit avoir qu’une seule responsabilité (S => Single Responsibility)
- Ouvert à l’extension mais fermé à la modification : (O => Open/Closed Principle)
- Le principe de substitution de Liskov : si B est un sous-type de A, alors il doit être possible de remplacer A par B sans compromettre la bonne exécution du programme (L => Liskov Substitution)
- Séparation des interfaces (I => Interface Segregation)
- L’inversion des dépendances (D => Dependency Inversion)
Les design patterns répondent à des problèmes de conception fréquemment rencontrés dans le cadre de la programmation par objets. Ce sont des solutions reconnues et éprouvées dont la conception provient de l’expérience de programmeurs aguerris.
Les design patterns sont basés sur les bonnes pratiques de la programmation orientée objet. Vous les utilisez peut-être déjà sans le savoir.
- Abstract Factory (Fabrique abstraite) : a pour objectif la création d’objets regroupés en familles sans devoir connaître les classes concrètes destinées à la création de ces objets.
- Builder (Monteur) : permet de séparer la construction d’objets complexes de leur implémentation de sorte qu’un client puisse créer ces objets complexes avec des implémentations différentes.
- Factory Method (Fabrique) : a pour but d’introduire une méthode abstraite de création d’un objet en déléguant aux sous-classes concrètes la création effective.
- Prototype : permet la création de nouveaux objets par duplication d’objets existants appelés prototypes qui disposent de la capacité de clonage.
- Singleton : permet de s’assurer qu’une classe ne possède qu’une seule instance en mémoire et de fournir une méthode unique retournant cette instance.
- Adapter (Adaptateur) : a pour but de convertir l’interface d’une classe existante en l’interface attendue par des clients également existants afin qu’ils puissent collaborer.
- Bridge (Pont) : a pour but de séparer les aspects conceptuels d’une hiérarchie de classes de leur implémentation.
- Composite : offre un cadre de conception d’une composition d’objets dont la profondeur de composition est variable, la conception étant basée sur une structure arborescente.
- Decorator (Décorateur) : permet d’ajouter dynamiquement des fonctionnalités supplémentaires à un objet
- Facade (Façade) : a pour but de regrouper les interfaces d’un ensemble d’objets en une interface unifiée rendant cet ensemble plus simple à utiliser.
- Flyweight (Poids Mouche) : facilite le partage d’un ensemble important d’objets dont le granularité est fine.
- Proxy : construit un objet qui se substitue à un autre objet et contrôle son accès.
- Chain of Responsibility (Chaîne de responsabilité) : crée une chaîne d’objets telle que si un objet de la chaîne ne peut pas répondre à une requête, il puisse la transmettre à ses successeurs jusqu’à ce que l’un d’entre eux y réponde.
- Command (Commande) : a pour objectif de transformer une requête en un objet, facilitant des opérations comme l’annulation, la mise en file des requêtes et leur suivi.
- Interpreter (Interpréteur) : fournit un cadre pour donner une représentation par objets de la grammaire d’un langage afin d’évaluer, en les interprétant, des expressions écrites dans ce langage.
- Iterator (Itérateur) : fournit un accès séquentiel à une collection d’objets sans que les clients se préoccupent de l’implémentation de cette collection.
- Mediator (Médiateur) : construit un objet dont la vocation est la gestion et le contrôle des interactions au sein d’un ensemble d’objets sans que ses éléments se connaissent mutuellement.
- Memento (Mémento) : sauvegarde et restaure l’état d’un objet.
- Observer (Observateur) : construit une dépendance entre un sujet et des observateurs de façon à ce que chaque modification du sujet soit notifiée aux observateurs afin qu’ils puissent mettre à jour leur état
- State (État) : permet à un objet d’adapter son comportement en fonction de son état interne.
- Strategy (Stratégie) : adapte le comportement et les algorithmes d’un objet en fonction d’un besoin sans changer les interactions avec les clients de cet objet.
- Template Method (Patron de méthode) : permet de reporter dans des sous-classes certaines étapes de l’une des opérations d’un objet, ces étapes étant alors décrites dans les sous-classes
- Visitor (Visiteur) : construit une opération à réaliser sur les éléments d’un ensemble d’objets. De nouvelles opérations peuvent ainsi être ajoutées sans modifier les classes de ces objets.
Les design patterns de construction ont pour but d’organiser la création d’objets.. Ils sont au nombre de cinq : Abstract Factory, Builder, Factory Method, Prototype et Singleton.
Les design patterns de structuration facilitent l’organisation de la hiérarchie des classes et de leurs relations. Ils sont au nombre de sept : Adapter, Bridge, Composite, Decorator, Facade, Flyweight et Proxy.
Enfin, les design patterns de comportement proposent des solutions pour organiser les interactions et pour répartir les traitements entre les objets. Ils sont au nombre de onze : Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method et Visitor.
Pour cet article, nous avons utilisé le livre ‘Design Patterns en PHP‘ comme source principale pour explorer les aspects théoriques des Design Patterns. Cette ressource a été très utile pour comprendre les concepts clés et les applications pratiques de ces modèles de conception.