Article mis à jour le : 05-05-2022
Petite description des différents pattern en PHPEn 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.
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.
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.
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.
Permet de lier des objets à des écouteurs, ces derniers ayant pour mission de prévenir d'autre objets d'éventuels événements.
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...
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.
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).
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.
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.
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.
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.