Le MVC est un design pattern qui est l’abréviation de Modèle-Vue-Contrôleur, et pour une fois, en anglais ou en français, ça fait les mêmes initiales (Model-View-Controller), donc y aura pas de débat sur comment qu’on doit causer. On raconte que son créateur se nomme Trygve Reenskaug, me demandez pas comment ça se prononce — son créateur, ou disons son théoricien, car comme souvent, on ne l’avait pas forcément attendu pour opérer de cette façon, mais il a mis des mots dessus (ce qui ne diminue pas l’importance de son travail).

Pour tout dire, quiconque a fait seul dans son coin des sites web dynamiques en mettant un peu (beaucoup) les mains dans le cambouis des langages/bases de données/exploitations multiples des mêmes informations, etc, a de fortes chances d’avoir à un certain niveau commencé à appréhender plus ou moins consciemment le MVC – ou alors, il a vraiment beaucoup galéré, et il est un petit peu décédé à l’heure qu’il est.
Moi qui vous parle, enfin vous écrit, avant de lire quelques livres intéressants sur le sujet et de découvrir des frameworks, j’en étais arrivé à travailler systématiquement avec d’un côté des méthodes d’accès aux informations (à peu près bien abstraites du système de base de données), de l’autre des fichiers traitant les sorties (pour le web, pour le XML, pour des usages internes…), et au milieu un ou plusieurs points traitant les actions des utilisateurs et décidant ce qui devait être mis en œuvre.

Bien sûr, n’ayant pas conscience clairement des enjeux de cette division (faute entre autres d’avoir mis des mots dessus ; d’où l’importance de nommer), il traînait de nombreuses erreurs d’organisation affaiblissant souvent pas mal l’ensemble. Mais le fond était là : porté par la nécessité interne des traitements récurrents nécessaires pour une application web, j’avais fait un premier pas sans même le savoir, tel le Monsieur Jourdain des design patterns, dans le monde merveilleux du MVC.

Le MVC, ou comment diviser pour mieux régner

Précisons avant d’aller plus loin que comme tout design pattern, MVC n’est pas spécifiquement dédié à une technologie, un langage ou quoique ce soit.
Il concerne de droit toute application avec une interface Homme-Machine, comme on dit (enfin, on dit IHM si on veut avoir l’air au courant), et consiste en une sorte de paradigme de l’organisation de l’application, séparant les données et leur vie (modèle), leur présentation (vue), et la gestion des événements (contrôleur).

Séparer le modèle et la vue repose sur une exigence au fond assez simple, qu’on pourra schématiser comme suit : il faut traiter d’un côté le « fond », de l’autre la « forme ». Je recours aux guillemets, non pas pour pourrir la lecture, mais parce que l’utilisation de ces deux termes et leur séparation semblent aller de soi, or comme tout ce qui « va de soi », elles méritent d’être questionnées. Il est illusoire de croire qu’il y aurait d’un côté du « fond » (du contenu, de la pensée…) et de l’autre de la « forme » (l’expression, qu’elle soit écrite, orale, artistique…)
Autant supposer qu’on peut sans autre forme de procès séparer la musique du son, ou l’objet de sa manifestation — ce fantasme de séparation n’est en fait qu’une autre version de l’illusion platonicienne de la chose en soi, « vraie » chose dont le phénomène serait une version dégradée dans notre pauvre monde d’apparences.
Non pas qu’il n’y ait pas un intérêt théorique capital à pouvoir considérer séparément ces aspects ; mais dans la réalité, je vous le dis, croyez-moi sur parole, le phénomène épuise tout ce qu’il y a à être de la chose, et la forme, comme je l’ai déjà formulé dans une note précédente, et exactement forme de son fond et réciproquement. Bref. J’ai clairement entamé un autre post ici, qui verra peut-être le jour une autre fois. Revenons à nos moutons.

Nos moutons sont le M, le V, et le C. Il n’aura échappé à personne, du moins à personne qui aura lu avec un minimum de concentration le billet précédent sur les prises électriques et les grille-pain (mais je reconnais qu’il faut du courage), qu’une organisation isolant bien ces trois aspects d’un programme est comme l’archétype du découplage.
Votre modèle (en gros, les données) peut changer de principe de stockage, de nature même si ça vous chante, pour peu qu’il soit correctement interfacé avec les autres couches du MVC, elles n’y verront que du feu. Le centre nerveux de votre application (le contrôleur, qui réagit aux actions de l’utilisateur et distribue les réponses) peut de son côté traiter n’importe quel type d’entrées et rediriger les sorties vers n’importe quel affichage, i.e. les vues. Vues qui de leur côté se contentent de mettre en forme (grosso modo) des informations, indépendamment de leur origine. J’ai failli dire « se contentent d’afficher », mais en fait, contrairement à ce que son nom laisse croire, une « vue » au sens du MVC ne résulte pas nécessairement en quelque chose de… visuel. Une vue peut-être par exemple un fichier XML, qui vivra sa vie ensuite selon le client (au sens informatique) qui l’a requis.

Quand l’intelligence gagne la matière

L’intérêt très concret de l’application du MVC est qu’il isole les opérations, donc que chacun n’a à s’occuper que de sa partie. Et comme dans la vie, c’est toujours mieux quand chacun ne s’occupe que de ce qui le regarde. Dans ma Normandie natale, on dit « Chacun son champ, les vaches sont bien gardées« . Eh bien on ne peut mieux formuler le principe du MVC.
En termes de développement, cette division conceptuelle vise à organiser les rôles par fonction, et à traduire les différences de nature en séparations opérationnelles. Comme si on faisait rentrer dans la chair du code, qui a priori n’en a que faire, un peu du sens des objets qu’on manipule. En contre-partie, dans un effet de résonance sémantique, j’irais bien jusqu’à dire : de récompense sémantique, le code, initialement « bête », gagne en intelligence d’organisation et d’évolution. Risquons la formule : bien utiliser le MVC, c’est insuffler de l’âme dans la matière. Ouaip. Pas moins.

L’ultime intérêt, non des moindres, est pédagogique : en s’efforçant d’appliquer cette discipline de conception et d’implémentation, on s’oblige à bien comprendre ce qui fait quoi dans son application. Et croyez-moi, c’est pas de la tarte.
Mais, une fois encore, une bonne méthode appliquée avec constance finit par insuffler plus que du mécanisme, et crée de l’intelligence. Et pas que dans le code. Dans le codeur également. C’est toute la puissance de la méthodologie : des idées régulatrices qui dirigent vers un endroit. Et même si on ne sait pas précisément où est l’endroit, on peut travailler à avancer dans la bonne direction, et à bien arpenter le chemin.
Car pour finir sur une touche étymologique du meilleur aloi, c’est précisément de là que vient le mot méthode : μέθα (méta, qui suit) οδός (odos, le chemin).

___________________________________

Image empruntée ici : http://www.marriedtothesea.com/archives/2007/Aug/

Comme je ne suis pas mécontent du début de la série consacrée à Symfony et à ma chère mère, et qu’il ne se passe pas une semaine, que dis-je, un jour sans qu’ici et là, y compris au bureau, la question d’expliquer Twitter ne vienne sur le tapis, jme suis dit comme ça, en mon for intérieur où je me parle beaucoup (en me tutoyant, ce qui parfois me laisse perplexe), que j’avais bien matière à noircir quelques div de considérations puissantes et péremptoires sur le sujet.

Entendons-nous bien : en octobre 2009, il n’est plus question de prétendre faire découvrir Twitter, la fréquence d’évocation du site de gazouilling étant à peu près quotidienne sur tous les médias, y compris les plus grand public, nul doute qu’à ce jour à peu près tout le monde sait que Twitter existe, du moins toute personne qui a un rapport fréquent à notre ami l’internet. Mais bon, tout le monde sait aussi que e=mc², ça ne veut pas dire que chacun sache expliquer vraiment ce que ça signifie pour autant (et je vous rassure, à part traduire les signes e, m, c, et le petit deux en l’air, je n’en sais pas des masses plus).

Après une comparaison aussi pertinente, négocions le virage pour revenir au milieu du chemin (encore trois métaphores de ce type et je suis le nouveau Heidegger).
On pourra aligner les « définitions » qui circulent ça et là ( « site de mini-messages », « service de micro-blogging »…), on n’aura éclairé personne qui ne sait déjà ce que c’est. Et c’est un premier indice de la spécificité de ce qu’on appellera la chose Twitter : il est d’une part impossible de la définir entre trois mots, et pire, il est d’autre part quasi-impossible d’expliquer « à quoi ça sert » à quelqu’un qui ne connait pas, qui n’a pas fait son expérience de Twitter.

C’est là le drame. Et en même temps le sublime (mais oui, rien que ça — si vous pratiquez un peu ce blog, vous aurez pu remarquer que je n’ai pas peur d’élever le débat comme on élève son verre, ou pas loin). Allez, lâchons les chiens de la formule qui tue :

Expliquer Twitter à quelqu’un qui ne l’a jamais utilisé, c’est comme expliquer les couleurs à un aveugle.

On pourrait, on devrait, même aller plus loin : non seulement il faut l’avoir déjà utilisé, mais il faut être rentré dedans, comme on rentre dans un livre un peu rebutant. Ça prend du temps, et la probabilité qu’on abandonne dans les premières heures ou les premiers jours est très élevée.
Dans le cas de Twitter, le « verdict » est au choix : « Twitter, c’est nul, c’est juste MSN en moins bien »,  « Twitter, c’est chiant, c’est pas ça qui va me faire quitter Facebook », ou autre « Dans Twitter c’est vraiment débile cette limitation à 140 caractères ».

Twitter, ça ne sert à rien

Tiens, parlons-en, des 140 caractères. L’explication historique, pour ceux qui auraient dormi ces trois dernières années, est que l’une des premières contraintes auto-imposée par les créateurs de Twitter était d’envoyer et de recevoir les messages, les tweets, aussi par SMS. D’ailleurs ça a marché partiellement au départ en france, en 2007 et jusque début 2008 et votre serviteur s’était pas mal amusé à bricoler quelques bots psychopathes qui pouvaient lui envoyer des SMS intéressants, notamment sur l’état du trafic RATP. Mais c’est un autre sujet.
Ces considérations autobiographiques de haute volée mises à part, je vois mal qui aurait en 2006 parié trois carambars sur l’avenir d’un service Internet contraignant ses utilisateurs à « s’exprimer » avec une limitation de caractères, qui plus est assez vite atteinte. A l’heure où le bit se négocie au milliard de kilos comme un vulgaire poste à l’EPAD, quelle hérésie… Eh bien non seulement ça a marché, mais ça a permis de montrer, s’il en était besoin, qu’abondance de caractères nuit parfois, et qu’au fond, si on a quelque chose à dire, on peut toujours le dire plus simplement. Ou sinon, c’est qu’on se trompe de medium.

Cette contrainte génétique est une chose ; elle n’explique pas pour autant en quoi définir Twitter est un exercice particulier, ni en quoi comprendre et surtout expérimenter l’intérêt de Twitter prend du temps.
La raison principale est simple : Twitter, en tant que tel, ça ne fait rien. Même si on peut accéder en pur spectateur à une partie des « messages » mondiaux, le cœur de Twitter n’est pas un site mais un service (au sens informatique), dont le rôle se borne, pour résumer, à permettre aux gens de s’inscrire, de poster des messages ou tweets, de « suivre » d’autres utilisateurs et d’être suivis (l’un ne nécessitant pas l’autre), le principe étant de regrouper et de visualiser en un seul « fil de message » tous les tweets des utilisateurs qu’on suit.
Comme ça, je vous l’accorde, ça a l’air et trivial et pas très intéressant.
C’est parce que tout reste à faire : une fois inscrit, il faut suivre des utilisateurs (un certain nombre d’entre eux vous suivra en retour, surtout si vous commencez à poster des messages). Lesquels ? Ben justement, tout est là : ça dépend de ce que vous recherchez. La difficulté étant que d’une part rien n’oblige à savoir exactement ce qu’on cherche (bah oué, c’est la vie, quoi), et que d’autre part, on peut chercher plusieurs sortes de choses.

Twitter, ça sert à tout

Voilà l’essence de la chose Twitter, qui traduit la difficulté qu’on aura toujours à l’expliquer : Twitter, ça sert à ce qu’on en fait. Encore faut-il donc s’y mettre activement, définir et inventer ses usages — qui peuvent être mêlés, et changer au fil du temps, ce qui concourt à la complexité de compréhension de la bête. Utiliser passivement Twitter, c’est vraiment s’embêter avec un remplaçant de lecteur de flux RSS peu performant .

Twitter, ça peut servir, dans l’ordre et le désordre, de manière absolument pas exclusive et parfois complémentaire, à :

• faire de la veille, en suivant des gens qui postent beaucoup de liens, et/ou des flux RSS repostés
• discuter de manière plus ou moins impromptue et décousue avec des gens qu’on connait
• discuter de manière plus ou moins impromptue avec des gens qu’on ne connait pas, voire les rencontrer ensuite dans la vraie vie
• raconter sa vie, qu’il s’agisse de détails insignifiants ou d’épisodes cruciaux
• promouvoir des choses qu’on aime, des sites intéressants, des services et pourquoi pas des choses qu’on vend
• taper sur des choses qu’on n’aime pas, râler sur la RATP ou la SNCF
• faire des recherches sur ce qui se dit sur tous les sujets imaginables
• suivre en direct des émissions de télé palpitantes (ou du moins les commentaires avisés qu’en font les partisans ou les détracteurs)
• participer à des sortes de cadavres exquis ou le multilinguisme le dispute à la variété des sujets
• jouer au kamoulox
• savoir quel temps il fait à Dunkerque ou New-York…

Et ce qui est vraiment très bien, et intellectuellement excitant, c’est que ça peut être tout ça, un peu de ça, d’autre chose, dépendre des jours, dépendre du vent, de votre humeur et de ce qui se passe dans le monde. Bien sûr, cet aspect polymorphe demande une certaine disponibilité, en termes de temps et de présence d’esprit au sens strict.
Il y a peu d’intérêt à venir sur Twitter (quelle que soit la façon dont on consulte son flux) une fois par mois, tout se passe vite, parfois dans l’immédiateté et la fugacité, ce qui n’équivaut pas nécessairement à de l’inutilité.
Mais on peut aussi laisser filer un, deux, dix jours, et revenir comme un fleur sans que ça soit rédhibitoire ; ça n’est ni un blog, ni un forum, ni irc, ni msn, ni facebook, ni la pierre philosophale, et pourtant éventuellement un peu de tout ça en même temps.

En résumé, Twitter, comme Internet à sa façon, ne peut être défini et surtout expliqué en une phrase, parce qu’il y a autant d’usages de Twitter que d’utilisateurs.

Le nerf de la guerre, c’est le choix des gens qu’on va suivre ; une bonne méthode, c’est d’y aller à la pelle au départ, de regarder qui suit qui, qui « répond » à qui (avec le signe magique @), et de désuivre rapidement, surtout dans les premières semaines. Comme pas mal de choses, la suite se fait… en se faisant, et le résultat ne sera pas forcément celui qu’on avait prévu.
En tout cas, pour peu qu’on fasse quelques efforts (mais c’est peut-être là une exigence trop forte), l’inhabituel et la surprise sont vite au rendez-vous ; le banal et le quotidien aussi, mais il ne faudrait pas non plus demander à la réalité d’être immédiatement plus géniale que les gens qui la font. Et rien n’oblige personne à utiliser Twitter, encore moins à suivre des utilisateurs prétentieux ou analphabètes (et je vous le donne en mille : ça fourmille).

Une autre fois, on détaillera peut-être les us et coutumes qui régissent plus ou moins la twittosphère, comme on dit.

______________________________________

Si le sujet vous intéresse, il continue ici : Twitter est-il pour tout le monde ?
______________________________________

Pour une fois, le champ lexical auquel le concept est emprunté n’est pas celui du BTP, même si on n’en est pas loin : c’est celui de l’électricité. Découpler y signifie supprimer le couplage entre deux circuits (ok, on est proche de la lapalissade, mais bon).

L’exemple le plus parlant sera celui de la prise électrique. Si on n’avait pas défini de standard ni  un principe de prises mâles et femelles, on vivrait dans un monde où les appareils électriques ne pourraient être vendus prêts à être branchés, où il faudrait  faire intervenir un électricien pour les raccorder au réseau, et où une fois installés on ne pourrait plus les déplacer ni les brancher ailleurs (sauf à répéter l’intervention). Assombrissons le tableau, et imaginons que dans ce même monde le réseau électrique n’aie pas de tension standard, mais distribue du 230 volts ici, 110 là, 3.14 ailleurs, etc. Non seulement il faudrait une manipulation technique pour connecter le grille-pain, mais aussi pour l’adapter à la tension. Manip’ à répéter à chaque déplacement de la bête…

Le problème que l’on aurait dans un tel monde serait celui d’un très fort couplage entre les appareils et le réseau électrique. Inutile de vous faire un dessin pour expliquer à quel point ça ne serait pas commode. Pour rester poli et ne pas dire chiant. Ah mince je l’ai dit.

En informatique, on s’est rapidement soucié du couplage, que ce soit du point de vue matériel comme pour les prises électriques en définissant des standards plus ou moins universels (PCI, RS232, USB, firewire…), ou logiciel (dans les programmes, ou dans les couches inférieures, par exemple le modèle adopté pour l’interconnexion des réseaux, OSI, mais c’est un autre sujet).

En ce qui concerne le sujet qui nous intéresse, le développement d’applications web via les frameworks en général et Symfony en particulier, le découplage est une notion critique.
Elle fonde l’organisation du framework lui-même, et sous-tend toutes les bonnes pratiques qui vont avec et doivent être appliquées dans le code spécifique à l’application.

Interfacer pour mieux découpler

Pour le formuler autrement, le découplage consiste en l’indépendance maximale de toutes les « briques » entre elles. Mais comme ces briques doivent communiquer, leurs interfaces, c’est-à-dire leur frontières de communication, doivent être codifiées.
C’est pourquoi en électricité on a réduit les nombres de connecteurs et définit des standards. C’est pourquoi en informatique on a défini des protocoles, autrement dit des règles d’échange. Car pour permettre le découplage, il faut se concentrer sur l’endroit — si je puis me permettre — où ça s’accouple, et l’abstraire des contingences et des spécificités (amen).

De la même manière qu’on ne souhaite pas avoir à changer de grille-pain si on change les prises ou si on déménage, on veut pouvoir faire abstraction, en développant une application web, de la façon dont l’accès aux données est géré (il nous suffit de savoir qu’il l’est), du type de serveur de base de données (on veut idéalement pouvoir utiliser n’importe lequel). Bref, on veut pouvoir se brancher dessus sans avoir à se demander comment. Aussi simplement qu’en branchant une prise mâle dans une prise femelle.
D’une manière générale, les fonctionnalités du framework doivent pouvoir être utilisées les unes indépendamment des autres, sans quoi leur mise en œuvre reviendra la plupart du temps à écraser une mouche avec un marteau-piqueur, ou pour rester sur notre champ lexical du jour, à faire construire une maison entière pour pouvoir brancher notre grille-pain.

Cette indépendance des « éléments » a un deuxième intérêt, non des moindres : il rend possible l’évolution ou la réparation des uns sans avoir à intervenir sur les autres.
Dans la vie bien découplée, vous pouvez acheter une cafetière neuve (ouaip, changeons d’objet électroménager, ça commence à devenir saoulant le grille-pain) sans avoir à refaire toute votre installation électrique, non ? Et bien si votre code et votre application sont eux aussi correctement découplés vous devez pouvoir modifier, mettons, votre logiciel d’envoi de mail sans avoir à retoucher à tous les endroits où vous envoyez des mails.

En résumé, si vous voulez briller en société (ou en lan party, encore que..) pensez à caser « découplage » au détour d’une saillie, ça fait toujours son effet. Si vous voulez briller en tests unitaires, c’est bien aussi, mais ça sera l’objet d’un épisode de la saison 2.

Dans le prochain épisode, cette fois c’est juré-craché-si-je-mens-je-vais-à-Denfert, on parlera de MVC…

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.

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. 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.

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

Ce framework porte le nom de Symfony, pour des raisons expliquées ici. Jusque là, fastoche. C’est ensuite que ça se complique. Déjà, rien que le premier mot : framework. Littéralement, cadre ou structure ; dans la programmation en général, on le traduit plus précisément par « cadre d’applications ». Enfin, on le traduirait, parce qu’on ne le fait jamais, on dit toujours frèmeouorque. A compter de cette phrase, je dirai d’ailleurs « framework » sans autre forme de procès, et même sans italiques (je suis comme ça, jsuis un gueudin).

Pour commencer, donc, qu’est-ce qu’un framework ? S’il y avait une réponse simple, on se passerait de ces lignes. La difficulté majeure tient à ce qu’il y a en fait dans la définition deux dimensions principales, complémentaires mais en partie indépendantes : un framework c’est à la fois une boîte à outils et une méthodologie. Ou, si on n’a pas peur des envolées lyriques : une boîte à outils fournie avec une philosophie.

Une boîte à outils

On a l’habitude de comparer un framework à un ensemble des « briques » toutes faites qu’on peut utiliser pour son application .
Si l’analogie n’est pas trop mauvaise, elle est insuffisante, parce qu’un framework c’est plus que ça. Cela dit, l’image de « brique » convient assez bien à ce qui circule çà et là sous le nom de composants (et d’ailleurs, le monde est bien fait, car certaines parties de Symfony sont justement mises à disposition comme composants : http://components.symfony-project.org ; dingue, hein ?)

Mais revenons à l’analogie de départ, même si elle est un peu faible ; elle dit qu’un framework est à un développeur ce qu’une boîte à outils est à un bricoleur.

Sous plusieurs aspects, un framework peut effectivement fonctionner comme une boîte à outils, en ce sens qu’il propose, dans le cas de Symfony du moins, un certain nombre de trucs pour faciliter le travail, l’accélérer, voire automatiser tout ou partie des tâches qu’on rencontre lors du développement d’une application web. C’est le côté work du framework, si l’on veut.
Enfoncer un clou, à la main, c’est douloureux et très long ; avec une pierre, moins douloureux, mais pas très précis. Avec un marteau, l’outil est assez optimal – même s’il ne dispense toutefois pas de taper. En plus, ce marteau a été testé industriellement, donc a de bonnes garanties de solidité .

Dans le développement web, on ne plante pas des clous, mais il y a des tâches équivalentes qui sont répétitives, peu gratifiantes, et d’autant plus sujettes à erreur qu’elles sont répétitives et peu gratifiantes : construction de bases de données à partir de leur schéma, import de données de test, initialisation d’interfaces d’administration, exécution de tests, gestion du cache, des urls…

Pour tout ça, le framework offre marteaux et tournevis, voire dans certains cas pistolets à clous. Ces « utilitaires »,  testés et mis à l’épreuve du feu par de nombreux développeurs, ont bénéficié de leurs retours d’expérience, leur efficacité et stabilité sont assurées par ce processus. Mais pas plus qu’un marteau ils ne dispensent pas de taper. Vous pouvez vous procurer une belle boîte à outils, ça ne fixera pas pour autant vos étagères au mur …

A un niveau un peu plus complexe, le framework (du moins Symfony) favorise l’intégration en deux coups de cuiller à pot de plug-ins, qui sont un peu comme les briques évoquées plus haut. Il en existe un grand nombre, pour des fonctionnalités plus ou moins évoluées (authentification, gestion de médias, de contenu…). On dépasse là le cadre de la « boîte à outils », et on est plutôt sur des objets de base qui font gagner du temps. C’est comme acheter des planches déjà découpées plutôt que de les scier soi-même. Mais ces objets conviennent rarement tels quels . Il faut les adapter à ses besoins. Par exemple peindre ses planches de la couleur qui va bien, choisir combien on en pose, à quelle distance les unes des autres…

Point crucial : dans le cas du framework, l’adaptation sera grandement facilitée par la méthodologie qui doit avoir été respectée par les créateurs des plug-ins. C’est-à-dire : si elle a été respectée.

Ce qui nous fait une transition toute trouvée pour le second aspect, non des moindres, de la définition d’un framework : en plus d’être une boîte à outils, un framework, c’est une façon de travailler.

Une méthodologie

Pour tenter une analogie, disons qu’un framework est à la programmation ce que grammaire et orthographe sont à la pensée.

On quitte là le champ lexical du bricolage pour celui de la linguistique, ou plutôt de l’apprentissage du langage . Glissement qui semble tout indiqué, puisqu’on parle de langage de programmation. Si on fouille un peu, on verra même que la nécessité de changer de champ répond en fait à une exigence interne, dictée par le caractère spécial des langages artificiels : un croisement génétique, pour ainsi dire, entre de la logique (qui se veut mécanique et déterministe) et de la pensée (qui reste inductive et poétique par nature, mais c’est une autre histoire).

Filons la métaphore. Quand on se met à programmer, on apprend une syntaxe, des fonctions, des mots-clés… ; bref, une sorte de grammaire et de dictionnaire .
Mais connaître par cœur l’intégral de la phpdoc ou autre n’a jamais fait un bon développeur, pas plus que réciter le Bescherelle n’a fait un grand auteur.

C’est là que, tel un cavalier qui surgit hors de la nuit (mince, ça y est maintenant j’ai la musique de Zorro dans la tête), intervient le framework. Il joue un rôle à la croisée de la rhétorique, de la littérature et de la logique :

• il énonce des conventions d’écriture et d’organisation destinées à rendre plus efficace, en homogénéisant et clarifiant
• il s’inspire des bonnes pratiques déjà existantes, notamment en termes de style
• il structure et favorise la discipline du code produit, et son indépendance à l’égard de toute solution logicielle ou matérielle.

En gros, il joue son rôle de « cadre » et de structure. C’est le côté frame du framework : il contraint à un certain nombre de choses, mais pour mieux libérer le processus intellectuel, en particulier en l’affranchissant des routines chronophages, et en aidant, par la clarté exigée, à faire face à l’augmentation de la complexité .

Si tout développeur qui connait un tant soit peu un langage (PHP en particulier, qui est plus facile d’accès que d’autres) est capable, même en tâtonnant, de mettre au point une application plus ou moins évoluée, l’expérience montre toutefois que son degré d’instabilité croît alors exponentiellement à la mesure de sa complexité, et que son code a tendance à devenir incompréhensible (et donc instable, indébuggable, non maintenable, etc…)

Pour faire face à la complexité, il faut être équipé de certains outils, intellectuels cette fois. Un framework a pour but de fournir de tels outils facilitant la modélisation des objets, de leurs relations, et des solutions aux problèmes posés. Il est à la fois une extension du vocabulaire du développeur et un perfectionnement de ses capacités grammaticales.
Du moins, il peut l’être. Car comme le marteau ne tape pas tout seul, le framework ne pense à la place de personne. Pire, comme un marteau, mal utilisé, il peut faire mal. Et s’il tend à structurer, il n’oblige ultimement personne à suivre sa méthodologie ; s’il peut aider à discipliner, il ne remplace pas l’auto-discipline qui est du ressort de ceux qui conçoivent et écrivent le code. Bref : un framework ça n’est pas la pierre philosophale qui changera votre code de plomb en or.

On se résume : côté pile, le framework est un cadre structurant, côté face, le framework est un outil facilitant le travail.
Finalement, on avait bien raison de garder le mot anglais.

Dans le prochain épisode, on parlera de design patterns…