N’utilisez pas les Design Patterns en PHP

N’utilisez jamais les Modèles de Conception, mais connaissez-les, maîtrisez-les !

Sous ce titre accrocheur (désolé) se cache tout de même un vrai conseil qui découle d’expériences malheureuses de développeurs enthousiastes ayant voulu se faire la main après une formation aux Patterns…. avec souvent pour résultat une conception trop lourde pour les besoins réels.

Ainsi, ne cherchez jamais à utiliser les Design Pattern, n’essayez pas de les inclure dans votre conception et surtout n’essayez pas de refactoriser votre code grâce à ces derniers sous prétexte d’en améliorer la souplesse future.

Par contre, étudiez les, comprenez les, relisez les, pensez à eux et accordez leur de l’attention.

Le jeu des métaphores

Si j’étais pianiste

Les Design Pattern sont l’équivalent des gammes : Elles développent la dextérité, elles entraînent l’esprit, il est indispensable de les connaître pour composer avec, mais seules elles ne représentent pas une oeuvre.

Imaginez la surprise du public si dans la lecture d’un programme à l’auditorium on pouvait voir « Gammes majeures jouées sur un rythme à 3 temps suivie d’une syncopées des Gammes mineures »

De la même façon, refactoriser la Sonate au Clair de Lune pour y inclure un parcours de la gamme de Do# Mineur pour aider le pianiste à ne pas avoir de crampes serait incompréhensible et répondrait à un faux problème.

Si j’étais un joueur d’échecs

Les Design Pattern sont l’équivalents des problèmes que l’on peut trouver dans les journaux (ou livres dédiés) : Ils mettent en exergue des aspects tactiques tels la déviation, le clouage, le détournement, les pions passés, l’interception, le sacrifice….. mais seuls il ne me permettent pas de comprendre la globalité du jeu, l’ensemble des problématiques et leur maîtrise n’est pas suffisante pour appréhender tous les aspects du jeu.

Bien sûr, leur connaissance peut me permettre d’identifier des solutions qui m’auraient normalement échappé, mais à tout prix vouloir sacrifier mes pièces est une mauvaise idée si cela ne sert aucun objectif concret, cela ne rendra pas mon jeu plus beau ni plus romantique, cela le rendra tout simplement mauvais.

Arrêtons de jouer

Les Design Patterns sont fantastiques s’il sont utilisés convenablement, s’ils sont utilisés à bon escient, s’ils sont étudiés avec raison, s’ils restent une source d’inspiration et non une finalité.

Les Design Patterns permettent d’échanger entre développeurs sur une façon de répondre à des problématiques courantes, ils présentent des cas d’études simples à comprendre et applicables à des conceptions plus importantes, ils proposent un catalogue d’architecture permettant au développeur débutant ou confirmé d’appréhender la programmation objet sous différents aspects.

Chaque pattern doit être utilisé si et uniquement si c’est nécessaire, sans quoi nous tombons dans des maladies connues telles la Singletonitis ou la « SeulLeDeveloppeurOriginalSaitCommentçaMarche ».

Un pattern n’est pas une solution figée, c’est la présentation d’une façon de faire pour répondre à une problématique courante, soyez en mesure de vous inspirer des pattern, et ne le laissez pas vous piloter, ne cherchez pas à transformer votre problématique en problématique courante pour utiliser un pattern la ou il sera une solution médiocre.

KISS – Keep It Simple, Stupid

Une solution élégante est une solution simple à écrire et à comprendre.

Aucun « Hello the World » au monde ne justifie l’utilisation d’un Pattern, comme aucun Hello the World au monde ne correspond réellement à un besoin utilisateur à automatiser.

Si une problématique peut être solutionnée en une ligne de code la ou un pattern justifie des centaines de ligne supplémentaires, n’hésitez pas à développer la version en une ligne. Ce n’est que si les solutions d’une ligne s’accumulent de façon déraisonnables que vous pourrez repenser à l’utilisation du pattern.

Si jamais….

Ne développez pas « si jamais », développez pour le cas présent. Avec des si, vous allez transformer un projet d’un jour en projet d’un mois. Si un pattern n’est justifié dans la conception que grâce à un « si jamais », alors il n’est pas justifié.

30 réflexions au sujet de « N’utilisez pas les Design Patterns en PHP »

  1. Ping : Tweets that mention N’utilisez pas les Design Patterns en PHP | Gerald's Blog -- Topsy.com

  2. 100% d’accord, même si je n’irai pas aussi loin en proscrivant l’utilisation pure et simple des patterns comme le titre — provocateur — le suggère 😉

    Un de mes acronymes préférés avec KISS et DRY c’est YAGNI : You Ain’t Gonna Need It. Je crois que je n’ai jamais rien rencontré de pire (et de démotivant) que le dev venant d’apprendre l’existence d’un pattern et qui le case à toutes les sauces pour se faire plaisir (au départ) quitte à ruiner l’application sur laquelle il bosse en bout de course. Le pair programming est un vrai remède préventif à ce type d’enfer, d’ailleurs.

    J’avais lu un truc de Kent Beck aussi qui parlait du « coût exponentiel de la ligne de code », en tenant compte de la maintenance, de la documentation, de l’impact sur les performances, du coût du tests, etc… mais j’arrive pas à remettre la main dessus :/

    Un truc marquant aussi c’est la difficulté qu’on beaucoup de devs à supprimer du code. Parfois même en sachant pertinemment que la voie empruntée n’est pas la bonne, ils vont persister dans la mauvaise direction coûte que coûte, entraînant un effet boule de neige fatal à bien des projets…

    • 100% d’accord, même si je n’irai pas aussi loin en proscrivant l’utilisation pure et simple des patterns comme le titre — provocateur — le suggère 😉

      Je suis d’ailleurs « pro pattern » et j’essaye autant que je peux d’en promouvoir la connaissance et l’usage. Le but du blog étant de recenser le plus de patterns possible et de les présenter en action, j’ai voulu faire un article pour modérer l’utilisation brute des exemples.

      Un de mes acronymes préférés avec KISS et DRY c’est YAGNI

      Je ne peux qu’être d’accord…

  3. Pour commenter NiKo:

    J’ai pu constater du pair programming contre productif aussi, trop de discussions.

    Le refactor doit entrer dans le processus de développement afin de maintenir le logiciel cohérent pendant son évolution.

    Sinon, au sujet de l’article, je suis aussi d’accord.
    C’est l’idée du pattern qu’il faut retenir.
    J’ai souvent vu l’implémentation du Singleton avec une méthode getInstance() parce qu’on le voit dans les exemples Java, alors qu’on peut utiliser un getter static suivant le langage.

  4. >> Aucun « Hello the World » au monde ne justifie l’utilisation d’un Pattern

    Position eXtreme : ON

    -> Aucune « application web écrite en PHP » au monde ne justifie l’utilisation d’un Pattern

    Preuve : C’est à vous de me démontrer le contraire (ie. Il existe une application web écrite en PHP, tel que l’utilisation d’un design pattern du gof apporte un plus quelconque à l’application.)

    Rappel : ma critique du singleton

    Position eXtreme : OFF

    • Aucune « application web écrite en PHP » au monde ne justifie l’utilisation d’un Pattern
      Preuve : C’est à vous de me démontrer le contraire (ie. Il existe une application web écrite en PHP, tel que l’utilisation d’un design pattern du gof apporte un plus quelconque à l’application.)

      La preuve est aisée : spl_autoload_register est une chaine de responsabilité, n’importe quelle application WEB PHP qui a recours à l’autoload prouve l’utilité des Patterns.

      Maintenant d’autres exemples :

      Un système de log configurable selon plusieurs stratégies (mail, disque dur, base de données, …)

      Un système d’authentification selon plusieurs sources (ldap, plusieurs bdd, …) (chaîne de responsabilité)

      Du couplage souple avec un système de tableau blanc (par exemple un système d’évènements)

      Une appli avec coloration syntaxique selon les langages

      Les fabriques ….. largement utilisées et intéressantes pour obtenir des objets configurés correctement, que l’on va retrouver dans moult librairies à bon escient.

      Les Itérateurs…. je ne détaille même pas

      Les poids mouches, histoire de ne pas inonder la mémoire du script pour afficher quelques données utiles

      Les proxy => je les ai utilisé pour mettre en session des objets avant le système d’autoload en PHP (l’objet proxy proposait des méthodes wakeup/sleep incluant les bons fichiers)

      Les décorateurs => Ce n’est ni plus ni moins une façon de faire de l’héritage sans ajouter de complexité à l’arborescence des objets…

      Les façades sont pratiques pour utiliser simplement, pour des besoins simples, des bibliothèques plus complexes….

      Les Patterns sont de très bons outils, utiles dans de nombreux cas, web ou non.

      Il est possible que tu n’ai aujourd’hui pas encore rencontré d’application web dans laquelle tu ai eu besoin de mettre en oeuvre un pattern, mais pour ma part, à plusieurs reprises et régulièrement, nous avons eu recours à des patterns avec succès.

      • > Un système de log, Un système d’authentification selon plusieurs sources (ldap, plusieurs bdd, …), une appli avec coloration syntaxique selon les langages :

        Le plus souvent, je résous ça avec une interface.(par exemple, dans mon DBDiff qui calculent les différences entre deux bases de données, il y a évidemment une interface et plusieurs implémentations concrètes pour chaque type de base)

        La factory : je l’ai utilisé, ca a toujours eu pour effet de complexifier affreusement le code. J’ai toujours regretté d’en avoir mis une, bien que le plus souvent, je ne sais pas trop comment m’en passé. Mais instinctivement, je « sens » que ca n’est pas beau (désolé si ça fait un peu mystique 😉 )

        > Les Itérateurs…. je ne détaille même pas

        Ben si, parce qu’en PHP, avec les tableaux associatifs, on est plus trop dans le même paradigme qui a conduit à l’utilisation de ce type de pattern. (http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures)

        Alors, attention, je ne dis pas qu’on devrait bruler les gens qui utilisent les patterns, mais que pour une appli web PHP, il y a intérêt a sacrément réfléchir avant d’être vraiment sûr qu’on ne peux pas utiliser autre choses qu’un Design Pattern du GOF (comme cette horreur)

        Allez, une dernière pour la route : http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

        • Le plus souvent, je résous ça avec une interface.([…], il y a évidemment une interface et plusieurs implémentations concrètes pour chaque type de base)

          Et bien bravo…… tu utilises à bon escient un pattern qui se nomme la « Stratégie ». Peut – on considérer que preuve est faite ?

        • J’avoue que j’aurais bien pris la défense de la fabrique abstraite…. mais je laisse cela à plus tard pour ne pas allonger les commentaires la ou il n’y a pas lieu 🙂

        • De grands frameworks PHP actuels usent des patterns, parfois avec zèle c’est vrai, mais ça nous évite à nous, petits développeurs sans prétention, de devoir écrire des tonnes de gluecode.

          Tu as en horreur l’abstract factory ? Tu ne pourrais pas supporter Lithium toi (http://lithify.me/)

    • Aucune application web créée par un nullard ne justifie l’utilisation d’un pattern, c’est sur. Si tu fais des applications web, et que tu n’utilises aucun pattern, j’espère que je ne travaillerai jamais avec toi, ou dans une boite dans laquelle tu es passé.

    • Bien sûr… une interface n’est « que » la représentation des capacités d’une classe.

      On peut utiliser une interface afin d’adapter un objet, afin de le décorer, d’en permettre la mise en proxy….

      Un cas encore plus simple, on peut avoir un objet qui implémente l’interface Serializable, ArrayAccess, Iterator ou autre, on peut alors difficilement parler de Stratégie…. je ne cherche pas à interchanger un algorithme mais je dispose simplement d’objets avec des possibilités particulières.

      Je peut choisir de créer une interface « peutEtreMiseEnCache » à certains de mes objets sans que cela soit une Stratégie mais simplement une capacité qui sera utilisable parmi une collection d’autres objets (et en profiter le moment venu).

        • Même si ta classe BDDiff n’est pas la plus pure implémentation du modèle papier Strategie, j’ai envie de dire que l’on s’en moque :-).

          L’utilité des pattern ne réside pas dans la théorisation à outrance sur la sémantique, elle réside (comme je veux le souligner dans l’article en question) dans l’étude, la compréhension, la manipulation, la source d’inspiration…

          Quand je disais que tu utilisais le pattern stratégie, je ne faisais pas spécialement référence à ta classe (que je ne suis pas allé voir, désolé), je faisais référence à ta citation « dans ce genre de cas, j’utilise généralement »

          Après, se battre sur la sémantique et la définition de ce qu’est un algorithme…. si lorsque l’on fait un select from dual au lieu d’un select from tables cela représente réellement un changement d’algorithme ou non…..il n’y a pas d’intérêt.

  5. Ping : Singleton, Multiton et alternatives | Gerald's Blog

  6. Ping : Joomla! 1.6: un baroud d’honneur avant disparation ? | truffo.fr

  7. Il ne faut pas non plus oublier les patterns qui ne font pas partie des GOF comme MVC qui sont (très) largement utilisés à l’heure actuelle dans la réalisation d’IHM.
    Je suis on ne peut plus d’accord avec l’apophtegme DRY et KISS que je m’efforce de garder à l’esprit au quotidient (quand le coté gourou de ma personnalité ne prends pas le dessus) mais je ne vais pas pour autant m’asseoir sur les patterns s’ils peuvent améliorer l’application.

    J’ajouterai cependant ceci à l’article: faites attention aux patterns que vous employez, les GOF, GRASP et autres P of EAA sont considérés comme des références mais méfiez vous des patterns (par trop) complexes qui ne méritent pas leur nom. J’ai perdu la référence d’un article ou on faisait état d’un soit-disant pattern qui était un mix de strategy, d’abstract factory et d’adapter qui devenait une entité monstrueuse (et indépendante qui sort de votre ventre après gestation) et impossible à cadrer dans une application à moins de construire l’application autours.

  8. Ping : Exemple d’incompréhension patternique | Gege2061's blog

  9. Merci pour cet article 😛
    J’ai devéloppé des sites de services utilisés par des milliers de personnes sans jamais utiliser de pattern. Mon premier pattern est la lisibilité, mon deuxième pattern est la structure et le partage des taches et mon tout est le bon sens.

    • Je vois d’après les commentaires que peu de gens ont reèlement une éxperience des patterns sur des applications web. Je peut vous assurer que vous pouvez vous en sortir sans patterns mais en les utilisants, le code est mieux structuré et on à moins de réprtition et de temps perdu, le developpement devient plus systematique et l’on perd moins de temps à la reflexion. De plus le code est plus reutilisable. Donc, que des avantages.

  10. En tout cas, en débutant oo curieux, en regardant tout cela de prés, en particulier MVC, je me dit que c’est quand même sacrement bien branlé. Les modèles ne sont pas des figures de style imposées, ni des modelés figés, non ?

    Pourquoi employer des expressions anglaises? KISS – Keep It Simple, Stupid

    On a exactement la même chose en France : ce qui ce conçoit bien, s’exprime bien. 😉

    J’aime bien quend ca fight et l’os à moelle est toujours dans les commentaires. Merci pour article et d’apporter ton expérience.

  11. Super article ! 🙂
    4 ans et demi en retard mais j’ai pourtant appris plein de choses !!!
    Comme quoi des fois on reste dans sa bulle et on ne se rends même pas compte des choses qui existent !!

    Je ne suis pas un pur dev d’un autre côté et je ne voulais pas m’encombrer de connaissances de dev mais finalement cet article m’a redonné envie de me plonger à nouveau dedans ! 🙂 Merci 😀

  12. Pas d’accord. Au fur et à mesure que l’on progresse, il m’est arrivé fréquemment de ne pas comprendre l’utilité réel d’organiser comme ceci son code etc… Et Que au final c’est le manque de compréhension d’un pattern (par exemple) qui nous aurait bien facilité la vie en terme de maintenance pour des applications et c’est encore plus vrai pour de larges applications web.

    D’où l’utilité indéniable et primordiale des designs pattern. pas forcément sur des sites web oneshot où il n’y aura que des petites maintenances. Et ça c’est une question de bon sens et non une affaire de goûts.
    J’ai encore des développeurs qui viennent me dire ou à d’autres: « mais pourquoi tu fais ça, c’est plus simple comme ça ».
    Où là est tout le problème car il y a un problème de compréhension dans la pratique de la programmation qui exige de « bien penser (faire au mieux) son code » ce qui appelle à avoir en tête la notion « d’architecture applicative ».
    Un Design pattern Adapter ou Factory très utile dans bien des cas. Chaque design pattern a son utilité propre et dans un contexte bien définit. Si on utilise un design pattern factory mélangé avec du Decorator dans cette même class et j’en passe il n’y a plus de séparation logique du code et de ses objets.

    Ce n’est pas pour rien que l’on identifie et fait une différence entre un développeur Backend et Frontend, le mieux est d’être les deux, car l’un comme l’autre apporte un plus sur la compréhension de ce que l’on va architecturer.

    Le bute aussi n’est pas de pondre des design patterns dans tous les sens, il faut toujours garder à l’esprit de pratiquer un code dit: Yin/Yang et cela vaut dans tous les domaines d’ailleurs.
    Un Cuisinier découvrant un aliment qu’il affectionne et en mettra dans tous ses plats finira par détériorer ses recettes au final.
    Pour un dev ou autre, c’est exactement pareil.
    Le bon usage logique et proportionnel.

    • shadow – nous sommes bien d’accord que les patterns sont utiles.
      S’il fallait résumer l’article, le message est « n’utilisez un pattern que si vous le maitrisez. Si vous ne maitrisez pas un pattern, étudiez le. Si vous rencontrez un problème avec un marteau dans les mains, prenez du recul pour y voir autre chose qu’un clou… sauf si c’est un clou. »

  13. B.U.L.L.S.H.I.T.

    Un strategy te transforme un switch-case de 10000 lignes un-maintenable en un truc bien plus facile à lire et auto-documenté.

    Puissions-nous ne jamais travailler ensemble.

  14. Le problème de ces classes toutes d’exceptions c’est que en effet on sort de la programmation ouverte , hélas de + en + d’applications open source ouvre leur code fermé . Au final lorsqu’on veut intervenir on intègre une prog classique, le projet se dénature il meurt . Et on se tourne vers un fournisseur d’architecture tel que symfony . L’auteur a raison pour de tel projet cela se justifie rarement pour les autres . Cobol a été et reste le langage le plus diffusé sans une goutte d’originalité de la part de ses utilisateurs

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *