Symfony expliqué à ma maman, 2ème partie : les design patterns

Prendre la quatrième à gauche et tourner à droite après la fontaine

Résumé de l’épisode précédent : un framework, c’est une boîte à outils, des briques de base, et une méthodologie pour développer mieux, plus vite, et de manière plus sûre (un peu comme ça, quoi). Mais si ça peut fortement aider, ça n’est pas magique, et ça demande de suivre les principes du framework lui-même.

Une partie des principes méthodologiques qui va avec un framework est  couramment regroupée sous le nom de design patterns. Une fois encore, on s’abstiendra de traduire l’expression (la version française préconisée étant patrons de conception, et ça sonne un peu Bergère de France…)

Pour faire court (dans un premier temps), disons qu’un design pattern est une façon de résoudre un problème type. Il ne s’agit donc pas d’une solution en tant que telle, mais plutôt d’une recette, c’est-à-dire la description d’une manière d’opérer face à un certain type de problème.

Historiquement, la théorisation des design patterns fait beaucoup référence, et c’est une chose qui ne nous étonnera pas, au domaine de l’architecture, de l’urbanisme et de la construction, notamment suite au travaux de Christopher Alexander dans les années 70.
Constatant que la conception en architecture en particulier, mais aussi en ingénierie en général, conduisait à affronter des problèmes récurrents (isolation, solidité des structures, communication entre l’intérieur et l’extérieur…) il abstrait des archétypes destinés à couvrir tous ces aspects[1].

Un pattern est ainsi à comprendre comme un « modèle » éprouvé reliant une solution à un problème dans un certain contexte.

Tout problème de conception, dirait Alexander, met en jeu un seul individu face à une immensité. Ce problème contient un certain nombre de variables qui, combinées en sous-ensembles, représentent un nombre de cas débordant rapidement les capacités limitées de son cerveau.
D’où l’intérêt de diviser et de hiérarchiser ces sous-ensembles pour les étudier à part, et recourir à ce qu’on pourrait nommer le bon sens collectif de l’histoire (capitaliser sur les solutions qui ont prouvé qu’elles marchaient).
Dès ses premiers travaux Alexander met l’accent sur la nécessité de comprendre les rapports entre les parties et le tout, et de savoir comment s’y prendre pour traiter ce tout. Ce que nous avons appelé dans l’épisode précédent faire face à la complexité.

De l’urbanisme à la POO

En 1995, les quatre mousquetaires du pattern, le bien nommé « Gang Of Four », s’inspirent d’une partie de ces travaux et transposent la méthode dans la programmation orientée objet[2]. Comme Alexander, même si la démarche est, disons, moins empreinte d’une sourde angoisse métaphysique quant à l’appréhension de l’infini, leur but est de proposer des outils conceptuels pour gérer la complexité, en l’occurrence, posée par certains problèmes récurrents en programmation.
Ils sont issus des bonnes trouvailles et des bonnes pratiques de générations de développeurs et dispensent ainsi, comme on dit souvent, de réinventer le fil à couper la roue[3].

J’avais commencé un paragraphe complet donnant un exemple (en choisissant le pattern bridge, un modèle assez « simple »), et j’ai renoncé, car on ne peut pas en dire grand chose sans évoquer la programmation orientée objet, que ma chère maman n’est pas censée connaître, donc qui déborde le cadre de cette page.
Je tâcherai de présenter en revanche dans un épisode prochain le MVC, un design pattern assez connu — qui est en fait, pour être rigoureux, une combinaison de patterns. Retenons juste ceci en attendant, et au risque de me répéter : il ne s’agit pas de classes ou de bouts de programme, mais de façons de structurer son modèle de données, son architecture, son application, et ultimement son code (quelque soit le langage objet).

En guise de conclusion, et pour s’éloigner définitivement d’Alexander, signalons qu’on parle aussi de temps en temps du négatif des patterns, les antipatterns.

Comme leur nom l’indique, il s’agit des façons de faire qui sont exactement ce qu’il faut éviter. On regroupe sous ce nom des pratiques hétérogènes aux noms parfois sympatoches, comme la coulée de lave (mise en production d’un code non stabilisé qui de fait devient de moins en moins modifiable, se « solidifiant » comme de la lave), l’ancre de bateau (code conservé pour des raisons « politiques », pour ne pas fâcher un développeur et/ou en se disant qu’il servira plus tard…), ou l’objet divin (méthode ou fonction servant à trop de choses, et dont on finit par ne plus trop savoir comment elle marche).
Elles sont évidemment, presque autant que les autres, utiles au développeur — qui aura toujours au début de son existence mis en œuvre, même à son corps défendant, au moins l’un d’eux, sinon presque tous.

Dans le prochain épisode, cette fois, on parlera de MVC…

___________________________________

Image du Schéma empruntée ici : http://www.simonwhatley.co.uk/coldfusion-and-design-patterns

________________________________________________
  1. Le livre fondateur, A Language Pattern: Towns, Buildings, Construction, 1977, Oxford U.P., présente ainsi 253 patterns, pas moins, couvrant tous les aspects de la construction et de l’urbanisme, de la distribution villes/champs dans une région à l’épaisseur et au matériau des murs intérieurs, en passant par les animaux de compagnie et les bancs publics — où les habitants doivent pouvoir faire la sieste. []
  2. Design Patterns : Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides, 1995, Addison-Wesley. []
  3. Comme on n’est jamais assez prudent, je précise que le deux expressions ici mélangées sans vergogne sont « réinventer la roue » et « inventer le fil à couper le beurre ». []

Tags : , , , , ,

6 commentaires sur “Symfony expliqué à ma maman, 2ème partie : les design patterns”

  1. NiKo :

    J’ai souvent entendu parler de « motifs de conception » plutôt que de patrons, ça sonne pas trop naze je trouve.

    Mais ça évite de chanter à tue-tête « merciiii patronnnn »[1] quand on règle un problème d’architecture logicielle, ça gâche la fête.

    [1] http://open.spotify.com/track/6pyLol0eRrx0XR55CBfItG (ça colle bien à #1sensiolabs, cette ritournelle, non ?)

  2. LaurentLC :

    Tu es notre Charlie Oleg du sud-ouest. Merci.

  3. NiKo :

    Du sud-est, s’il te plaît. (tu rebois, hein, c’est ça ?)

  4. LaurentLC :

    Tu sais, une fois passée la porte d’Orléans (voire la place Denfert-Rochereau), je ne vois plus trop la différence, tout est au « Sud ».

  5. NiKo :

    Sinon le lien vers chez Simon Whatley est pété. (comme toi)

  6. LaurentLC :

    fixed in r1798