Les design patterns PHP avec Symfony : comment faire croire qu’on sait ce qu’on fait
J’ai ouvert la ouvert la boîte de Pandore avec le MVC et l’ADR, alors parlons des design patterns : c’est pas juste du copier-coller depuis Stack Overflow.
Aujourd’hui, on va parler des design patterns les plus utilisés en PHP avec Symfony. Parce qu’après tout, rien de tel qu’un bon jargon technique pour se la raconter à la pause-café ou impressionner son boss qui n'y comprend rien.
Singleton, ou le roi du raccourci
Le Singleton, c’est le mec qui débarque dans ton projet et dit : « Non, mais moi, y'en aura qu'un, c'est compris ? ». Un peu comme le dictateur du PHP : une seule instance partout dans l'application, parce que gérer plusieurs instances, ça fatigue les développeurs paresseux que nous sommes.
Exemple de Singleton
class DatabaseConnection
{
private static ?self $instance = null;
private function __construct() {}
public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
}
Repository, ou comment bien ranger ses chaussettes
Le Repository, c’est le rangement IKEA du PHP. Son job, c’est d’aller fouiller dans la base de données et de nous rapporter exactement ce qu’on cherche, proprement et rapidement, sans qu’on ait à se salir les mains avec des requêtes SQL dégueulasses écrites à la va-vite à 3h du mat.
Exemple de Repository
class ArticleRepository extends ServiceEntityRepository
{
public function findLatestArticles(int $limit): array
{
return $this->createQueryBuilder('a')
->orderBy('a.createdAt', 'DESC')
->setMaxResults($limit)
->getQuery()
->getResult();
}
}
Factory, ou comment déléguer intelligemment
Le Factory, c’est ton pote malin à qui tu délègues toujours les tâches pénibles. Son boulot, c’est de fabriquer des objets compliqués sans que t'aies à connaître tous les détails du bazar. T'as juste à demander, il fait le reste, tranquille.
Exemple de Factory
class ArticleFactory
{
public static function create(string $title, string $content): Article
{
$article = new Article();
$article->setTitle($title);
$article->setContent($content);
$article->setCreatedAt(new \DateTime());
return $article;
}
}
Observer, ou le fanboy du PHP
L’Observer, c’est ce gars qui t’espionne constamment pour savoir ce que tu fais. Quand quelque chose se passe, il saute dessus pour exécuter une action, comme un fan devant son idole. Utile mais parfois légèrement envahissant.
Exemple d'Observer
class ArticleSubscriber implements EventSubscriberInterface
{
public static function getSubscribedEvents(): array
{
return [
ArticlePublishedEvent::class => 'onArticlePublished',
];
}
public function onArticlePublished(ArticlePublishedEvent $event): void
{
// Fais un truc sympa ici, genre notifier tout le monde
}
}
MVC, l'incontournable classique
Le MVC, c’est le patron ultime que tu sors à toutes les sauces. Il divise ton application en trois couches : Model (qui gère les données), View (qui affiche joliment les données), et Controller (le messager qui fait passer les infos entre les deux autres). Même si, en vrai, ça finit toujours un peu mélangé. Mais bon, au moins sur le papier, ça fait sérieux. Par ici pour en voir le MVC en détail.
ADR, ou comment moderniser MVC sans trop se fatiguer
ADR, c’est le MVC revisité pour ceux qui trouvent le MVC trop mainstream. Ça divise le boulot autrement, avec une Action qui encaisse les requêtes, un Domain qui fait vraiment le boulot, et un Responder qui emballe tout ça proprement. C’est pareil, mais avec des noms différents pour impressionner les collègues. Par ici pour en savoir plus sur l’ADR
Pourquoi utiliser des design patterns ?
Parce que dire « J’ai utilisé un Factory avec un Observer branché sur mon Repository », ça fait toujours classe dans une réunion.
Et accessoirement, parce que ça aide à structurer ton application en évitant qu’elle ne ressemble à ta chambre. Mais bon, entre nous, même avec tous ces patterns, on sait tous très bien comment ton projet finira !