Dynamic-Mess.com


"The world is a dynamic mess of jiggling things..."

Singleton, Dependances, factory, strategy : Les différents pattern en PHP

Article posté le 07-01-2014 dans la catégorie PHP

En PHP comme dans les autres principaux languages de programmation, il existe plusieurs pattern ou "modèle" de programmation. Ces patterns permettent de résoudre des problèmes de conception fréquemment rencontrés, mais également d'augmenter la qualité et la "maintenabilité" du code.

Voici donc les principaux patterns.

Design pattern

Mode de conception, patron de conception. Il s'agit d'un mode d'approche, d'un mode de fonctionner, pour résoudre un problème particulier. A ne pas confondre avec un architecture pattern.

Architecture pattern

Manière dont est structurée votre application. On parle vraiment d'architecture, par exemple : MVC. MVC est un des plus connus, le code de l'application est découpé en trois couches: une couche présentation (la vue), une couche décisionnelle (le contrôleur), et une couche métier, appelée aussi business logic, avec tous les traitements propre au métier que gère l'application, la sauvegarde de données... Selon les applications, le degré et la permissivité des communications entre les couches varies, mais généralement, il ne faut pas confondre avec un concept assez proche: une architecture 3-tiers, où une couche ne peut communiquer qu'avec la ou les couches adjacentes.

Pattern factory (ou Factory Pattern)

Déléguer la création d'instances à une ou des classes "usines". Il s'agit par exemple d'une classe générique qui gère l'istanciation de classes spécialisées ayant chacune la même fonctionnalité mais la gérant différemment. Par exemple, sauvegarder des données, peut être fait dans une base SQL, fichier XML, CSV, txt... Un autre type d'exemple: dans les framework modernes, on ne doit plus instancier ses entités de cette façon: $maVoiture = new Voiture();. On doit passer par la factory: $maVoiture = $this->voitureFactory->create(); L'avantage de déléguer cette construction est que cela permet à la factory de gérer l'injection de dépendance dans les objets à créer.

Pattern Observer

Permet de lier des objets à des écouteurs, ces derniers ayant pour mission de prévenir d'autre objets d'éventuels événements.

Pattern Strategy

Séparer l'algorithme du code d'une fonction de cette dernière afin de faciliter sa réutilisation, et éviter ainsi de dupliquer ce dernier. Il s'agit par exemple de créer des classes qui implémentent des interfaces définissant le patron, les noms des méthodes...

Chain of responsability

Lié au Pattern Strategy, cela consiste à créer une classe respectant le principe SOLID: responsbilité unique, et permettre ainsi un héritage multiple "propre" en évitant les classes fourre-tout.

Pattern singleton

Consiste à empêcher qu'une classe ne soit instanciée plus d'une fois. Cela sert à accéder à une ressource qui n'est ainsi jamais dupliquée, par exemple une connexion à la BDD. La manière dont elle est conçue fait qu'elle est accessible depuis partout dans l'application sans que l'on ait besoin de garder une traçe d'elle : son constructeur est privatisé, et on accède à l'instance via une méthode statique. Voir un exemple en php ici (code).

Pattern injection

Celui là est très important. Une dépendance est une classe dont dépend une autre pour fonctionner, par exemple PDO. On parle d'ailleurs d'injection de dépendance" quand on injecte une classe dans une autre, en la passant en paramètre.

Registry pattern

Classe qui gère des singletons. Cela est utile par exemple pour gérer des connexions à différentes bases de données. Dans Magento 2, il permet de gérer les instances de classes, et de demander si on veut un singleton ou une entité unique.

Active Record pattern

Utilisé par certains ORM, on le rencontre quand une classe implémente une interface avec les signatures des méthodes pour l'accès (sauvegarde, suppression) à la base de données de manière opaque. L'utilisateur n'a pas à se soucier comment les données sont gérées en BDD, il a juste à se soucier des données. Il s'agit de l'opposé du Repository pattern, qui utilise une classe qui contient les méthodes pour faire du CRUD.

Proxy pattern

Egalement appelé "lazy loading": un objet est couteux en ressources ou en temps, donc on passe par une méthode pour l'appeler plutôt que l'appeler directement. La méthode se chargera d'obtenir cette instance si elle n'existe pas déjà, avant de vous la retourner. Cela évite d'avoir à systématiquement créer un objet alors que l'on est pas sûr d'en avoir besoin.


Tweet
comments powered by Disqus