« Convention over Configuration » (on trouve parfois une traduction par « convention plutôt que configuration), ce design pattern (ou patron de conception, pour faire plaisir aux francophones intransigeant) est un des plus intéréssant de ceux à la mode en ce moment.

Le principe en est très simple: les applications se basent sur des conventions au lieu de se baser sur des fichiers (ou autre) de configuration.

Plus clairement:

• Réduire le nombre de fichiers de configuration
• Configurer par défaut les applications (donc, sans aucun fichiers, base de données ou autres stockant ces informations de configuration) en se basant sur les standard (les conventions) du milieux
• Possibilité d’écraser cette configuration par convention par un fichier de configuration : l’application se configure toute seule en se basant sur des conventions, et si nécessaire, on peut écraser cette configuration par défaut via des informations de configurations dans un fichiers de configuration (ou base de données ou autre).

Ce principe est la base de certains frameworks dont:

• Ruby On Rails (RoR) : basé sur le language Ruby, ce framework exploite totalement ce design pattern en proposant des comportements par défaut pour toutes les fonctionnalités. Il permet donc en quelques sorte de ‘générer’ une application web CRUD (Create-Read-Update-Delete) depuis une simple description d’un objet.
  
• Trails : framework de développement JAVA basé sur le principe de Ruby On Rails
• AppFuse : décrire AppFuse est assez compliqué, de plus je ne l’ai que brièvement testé. En gros, c’est un générateur de squelette de projets. Il permet très facilement de générer un squelette de projet (un espèce de projet ‘vide’) prêt au développement basé sur un ensemble de framework reconnue (tel que Spring et Hibernate). Il se base sur des convention pour pré-configurer ces squelettes de projets.

D’un certain coté, l’utilisation de Spring permet aussi de mettre en pratique plus facilement ce design pattern car il comprend, pour beaucoup de partie du framework, une configuration par défaut qui peut être ré-écrite au moyen de son fichier de configuration. Bien que n’étant pas basé sur ce principe il l’utilise et en simplifie sa mise en place par ses possibilité de centralisation de configuration, sa gestion de l’AOP et ses nombreuses classes de support qui permettent une utilisation simplifié et conventionnelle de nombreux framework tiers.

Java lui-même donne un moyen très puissant grâce aux annotations pour mettre en pratique ce design pattern, en effet, via les annotations on peut mettre en place un comportement par défaut de certaines classes puis, via les fichiers de configuration ré-écrire si nécessaire ce comportement par défaut (c’est, par exemple, ce que fait Spring qui peut se configurer via les annotation et ses fichiers de configuration, la configuration par fichier ré-écrivant celles par annotations). L’utilisation des annotations dans le sens de convention et non pas configuration couplé à l’utilisation d’un fichier de configuration est une manière simple de mettre en place un design pattern convention over configuration. Car il ne faut pas oublier que pour être efficace, il faut la plupart du temps pourvoir ré-écrire ces conventions via des iformations de configuration (on parle donc de convention qui représentent une configuration par défaut)

L’AOP (Aspect Oriented Programming ou en français: Programmation par Aspect – POA – Programmation Orienté Aspect) peut aussi trés souvent aider à définir des comportements par défaut de l’application, dans ce sens, l’AOP est une aide formidable pour mettre en pratique ce pattern.
On peut par exemple, définir que toute la couche de service, par défaut, est mis en cache grâce à un aspect; les annotations nous permettant alors de définir certains services qui ne devront pas être mis en cache. Grâce à l’AOP je définit une convention plutôt qu’une configuration, les annotations me permettant, si nécessaire, d’introduire des exception (qui sont aussi, d’une certaine manière une convention : mon annotation @noCache étant une convention pour exclure un service du cache). Et dire qu’avant je devait définir dans un fichier de configuration les méthodes caché et non caché une par une …

Un des plus gros avantage d’appliquer ce pattern est de réduire énormément la taille de vos fichiers de configuration et d’accroître la lisibilité de votre code en utilisant des conventions de développement.