Design patterns et bonnes pratiques
DRY : Don't Repeat Yourself, ne vous répétez pas !
DRY est l'un des principes les plus importants en développement d'applications, et pas uniquement pour le Web. Qu'on en ait conscience ou non, ce principe est présent en informatique depuis de très nombreuses années.
N'apprend-t-on pas aux programmeurs débutants à ne jamais dupliquer de portions de code, mais à les factoriser dans des routines uniques (fonctions, méthodes…) que l'on appelle au besoin ? C'est une manière de ne pas se répéter, tout simplement.
Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité.
Andy Hunt et Dave Thomas dans The Pragmatic Programmer
Un exemple concret sur le Web : liens hard codés…
Une des applications les plus parlantes de la philosophie DRY sur le Web est l'écriture des URL dans les liens.
Imaginez que vous ayez mis en place un blog sur votre site, et que vous ayez défini un pattern d'URL pour chaque billet du blog. Par exemple : /blog/billets/id_billet/.
Maintenant, imaginez que vous éditez une portion de code faisant mention de billet du blog. Vous serez peut-être tenté, naturellement, de « hard coder » l'URL de la page de destination dans le lien, comme ceci : '<a href="/blog/billets/' + billet.id + '/">' + billet.nom + '</a>'. Et là, c'est le drame : vous commencez à vous répéter…
Plus tard, vous décidez de modifier le pattern d'URL des billets de blog, disons par exemple en y ajoutant des mots clés issus du titre de la page à des fins de SEO : /blog/billets/comparaison-django-rails,42.html.
Les URL de vos billets sont plus sympas à présent ! Mais tous les liens hard codés que vous avez pu faire de la manière décrite ci-dessus sont morts. Dommage, il va falloir repasser dans toutes vos vues pour corriger les URL que vous avez reconstituées.
En appliquant le principe DRY à cette problématique, les concepteurs de frameworks comme Django mettent en place des fonctions utilitaires permettant de calculer dynamiquement les URL de pages spécifiques. Notre lien devient, du coup, quelque chose du genre : '<a href="[billet id=billet.id]">' + billet.nom + '</a>'. Nous verrons un peu plus tard la syntaxe précise employée par Django pour écrire ce genre de chose.
MVC : Modèle-vue-contrôleur (model-view-controller)
MVC est très répandu de nos jours. Si bien qu'on oublierait presque qu'il a été inventé dans les années 70, à une époque où les applications web n'étaient pas vraiment légion. Autant dire que ce pattern ne s'applique pas qu'au Web…
Le principal intérêt de MVC est la séparation des préoccupations, chaque problématique est gérée séparément :
- La description des données manipulées par une application et des moyens d'accéder/manipuler ces données sont décrites dans les modèles.
- Les écrans affichés (le « rendu ») sont décrits dans les vues.
- Enfin, les contrôleurs sont les chefs d'orchestre qui, à partir d'une sollicitation de l'utilisateur (généralement, accès à une URL), font appel aux modèles pour récupérer les données et éventuellement les mettre à jour, puis demandent le rendu de la vue attendue.
Modèles, vues et contrôleurs sont généralement écrits dans des fichiers différents, ce qui permet notamment aux différents membres des équipes d'accéder aux ressources qui les concernent (par exemple les intégrateur n'interviennent pas sur les modèles, mais fréquemment sur les vues).
Nous en reparlerons plus tard, mais malgré le fait qu'il implémente fidèlement et efficacement le patron MVC, Django opte pour une dénomination légèrement différente :
- Modèle = Model (pas de surprise…)
- Vue = Template
- Contrôleur = View
En Django, ce qu'on appelle view est donc un contrôleur. Ce n'est pas méchant mais mieux vaut le savoir…
Active record
Active record est le design pattern derrière les ORM (Object-relational mapping). En fait, on dit que les ORM implémentent le design pattern active record.
Ce design pattern définit une stratégie d'accès aux tables et lignes d'une base de données via des objets métier, aussi bien pour la lecture que pour l'écriture en base. Le programmeur n'écrit donc pas de SQL, mais appelle des méthodes du type mon_objet.save() sur ses objets métier pour déclencher des actions de persistance côté SGBD.
Quelques lectures…
Design patterns : catalogue des modèles de conception réutilisables
Design Patterns - Les 14 principaux patterns
