Soirée design pattern et anti pattern en PHP

Présentation théorique des design pattern

La soirée a débuté par une présentation théorique des design pattern par Julien Pauli, avec définition de ce qu'est un design pattern :

Un patron de conception (design pattern) est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels.

Puis des principes SOLID sur lesquels sont basés les design pattern :

• Single responsability : pas trop de responsabilité pour une seule classe
• Open/Close Principle : ouvert à l’extension, fermé à la modification
• Liskov Substitution : un objet peut utiliser le fils de A sans s’en rendre compte (Héritage strict, et type conservé)
• Dependecy Injection : Si un objet A a besoin d’un objet B , ce dernier doit lui être injecté, il ne doit pas aller le chercher lui-même (donc pas de new Toto à l’intérieur d’une classe)
• Interface aggregation : A ne doit pas utiliser B directement mais une interface de B

Après quoi Julien a présenté quelques exemples de design pattern comme :

• le Singleton : restreindre l'instanciation d'une classe à un seul objet. Ce design pattern se révèle être en fait être un anti pattern car le Singleton ne peut être mocké pour les tests.
• L’Observateur/Sujet : le sujet envoie un signal à des modules qui jouent le rôle d'observateurs sur certains événements. Ce design pattern est  utilisé par exemple pour le principe de plugins dans Joomla.
• Le médiateur : quand un objet central contrôle un flux de messages
• Le décorateur : permet d'attacher dynamiquement de nouvelles responsabilités à un objet ce qui permet de résoudre la problématique de l’héritage multiple.
• L’itérateur : qui redéfinit la manière dont PHP parcourt un objet. Ce design pattern est par exemple utilisé par le composant Zend_Paginator de Zend Framework

(Anti pattern : fausse bonne idée, quand une solution génère plus de problème qu’elle n’en résout.)

Les design pattern en pratique

Voilà pour la théorie, Hugo Hamon a ensuite enchaîné par des exemples concrets d’utilisation des ces design pattern.

Hugo a commencé par présenter l’utilisation du design Pattern Observateur dans le composant Symfony Event Dispatcher, en détaillant la mise en place des écouteurs et du Sujet dans le cas concret de modification d’un article.

Il a ensuite détaillé l’utilisation du design pattern Injection de dépendances, en commençant par montrer en quoi la non-utilisation de ce pattern pouvait devenir gênante en prenant un cas simple d’envoi  de mail. Le code présenté était fonctionnel, mais pas évolutif, et il n’incluait pas de possibilité de modification de paramètres selon un environnement différent.

La mise en place d’un code respectant l’injection de dépendances impliquait un découplage avec les interfaces et une  construction un peu plus complexe, mais qui permettait des évolutions et des utilisations différentes selon l’environnement.

Hugo a ensuite rapidement évoqué l’utilisation de Pimple pour simplifier cette utilisation de l’injection de dépendances.

Pour cette deuxième partie je vous renvoie vivement à ses slides accessible sur https://speakerdeck.com/u/hhamon/p/design-patterns-avec-php-53-symfony-et-pimple

Retour d'expériences sur le design pattern Façade

La conférence s’est terminée sur un retour d’expériences de Theodo par Fabrice Bernard avec l’utilisation du design pattern Façade dans le cadre de reprise d’un site existant.

Le design pattern Façade permet en fait de simplifier une interface complexe. L’équipe de Theodo a donc utilisé ce design pattern pour  faire communiquer un ancien modèle comportant une partie modèle fortement couplée avec leurs nouveaux modules. Ils ont en fait procédé en deux couches :

Il ont d’abord mis une première façade composée de trois modèles communiquant entre eux (User, Match, Bar)  qui communiquait avec le modèle existant, puis ils ont mis une deuxième façade, composée de modules plus fins (un module par fonctionnalité), qui communique avec cette première façade. Cette conception a permis de conserver l’existant et ses fonctionalités tout en ajoutant de nouvelles fonctions sur un modèle plus propre.

La soirée s’est ensuite terminée par un apéro-saucisson-fromage offert par Theodo, où se sont tenus de nombreux échanges, et je l’espère d’où sont nées plusieurs idées de conférences pour le PHP Tour de Nantes (un appel aux conférenciers est en cours, je le rappelle !).

Un grand merci à Adrien pour m’avoir indiqué dans quelle direction aller face à un problème de reporting, à Stéphane, que j’ai été ravie de recroiser, et avec qui discuter est toujours aussi intéressant ! Ainsi qu’à toutes les autres personnes avec qui j’ai pu échanger au cours de cette soirée.

Si cette soirée vous a plu, pensez à adhérer à l’AFUP.

Merci aux conférenciers pour leur participation, à Theodo pour son sponsoring et à Eyrolles pour la salle.

L’antenne locale parisienne organisera un apéro PHP pour Septembre, d’ici là bonnes vacances à tous!