La «convention sur la configuration» ne contrevient-elle pas aux principes de base de la programmation?

Je regardais le framework WPF MVVM Caliburn.Micro et ai lu que beaucoup d'éléments standard sont basés sur des conventions de dénomination .

Par exemple, liaison automatique des propriétés de la vue aux propriétés du modèle de vue. Bien que cela semble être pratique (supprime du code standard), ma première réaction instinctive est qu’il n’est pas tout à fait évident pour un nouveau programmeur qui lira ce code. En d'autres termes, la fonctionnalité de l'application n'est pas complètement expliquée par son propre code, mais aussi par la documentation du framework.

MODIFIER:

Donc, cette approche s'appelle convention sur la configuration. N'ayant pu trouver aucune question à ce sujet, j'ai modifié ma question:

Ma question est:

La convention sur la configuration est-elle un moyen correct de simplifier les choses ou viole-t-elle certains principes de programmation (et si oui, lesquels)?

Je ne considère pas "une application doit être entièrement expliquée par son propre code", principe fondamental de la programmation. Il y a des tas de choses qui ne s'expliquent pas en regardant simplement le code d'une application. Outre la connaissance des éléments de base du langage de programmation lui-même (syntaxe et sémantique), vous devez connaître les conventions. Si un identifiant en Java commence par une lettre majuscule, il s'agit d'un type. Vous devez connaître bon nombre de ces conventions.

La convention sur la configuration consiste à réduire le nombre de décisions que le programmeur doit prendre à propos de choses. Pour certaines choses, cela est évident - personne n’envisagerait d’utiliser une langue dans laquelle la capitalisation des types est quelque chose que vous devez déclarer au sommet de votre programme - mais cela n’est pas si évident.

Équilibrer convention et configuration est une tâche difficile. Trop de convention peut rendre le code déroutant (prenons les variables implicites de Perl, par exemple). Une trop grande liberté du côté du programmeur peut rendre les systèmes difficiles à comprendre, car les connaissances acquises d’un système sont rarement utiles lors de l’étude d’un autre.

Un bon exemple de convention aide le programmeur à écrire des plug-ins Eclipse. En regardant un plugin que je n'ai jamais vu, je sais tout de suite beaucoup de choses à ce sujet. La liste des dépendances est dans MANIFEST.MF, les points d’extension sont dans plugin.xml, le code source est sous "src", et ainsi de suite. Si ces éléments devaient être définis par le programmeur, chaque plug-in Eclipse serait différent et la navigation dans le code serait beaucoup plus difficile.

Donné +1 à @JesperE, et souhaite ajouter quelque chose:

enfreint-il certains principes de programmation

Oui, "convention over configuration" viole le principe "explicite vaut mieux qu'implicite" (regardez, par exemple, "Zen-Of-Python" ).

D'autre part, la configuration opposée "configuration sur convention" a tendance à violer "Simple est meilleur que complexe", et pire, enfreint le principe DRY de manière subtile, car vous devez répéter les noms utilisés dans votre code également dans votre configuration. .

Certaines des "conventions sur la configuration" se résument à des valeurs par défaut raisonnables. Vous ne devriez avoir à configurer que quelque chose pour l'utiliser à des fins non standard. Je dois comparer Struts à Rails ici. Dans Rails, vous devez placer vos "actions / écrans" dans un dossier, puis ils fonctionnent. Dans Struts, vous devez toujours les placer dans un dossier, mais vous devez également définir un nom d'action ET un fichier JSP ET un nom de formulaire ET un bean de formulaire ET spécifier la manière dont ces trois éléments fonctionnent ensemble dans Struts-config. xml AND spécifie que le formulaire appartient à la requête (RESTful). Si cela ne suffit pas, le mappage formulaire / formulaire-bean a sa propre section dans Struts-config qui est ensuite mappée indépendamment vers la section action du même fichier. Tout repose sur des chaînes manuscrites dans le fichier JSP afin de fonctionner. correctement. Pour chaque écran, c'est au moins 6 choses que vous ne devriez pas avoir à faire et autant d'opportunités de faire une erreur. Je pense que vous pouvez définir la plupart ou la totalité de ces éléments manuellement dans Rails si vous en avez besoin, mais les 2/3 du temps de développement de Struts sont utilisés pour créer et conserver des niveaux de complexité inutiles.

En toute justice, Struts 1 a été conçu pour permettre aux utilisateurs de transférer des applications entre le poste de travail et le Web. La flexibilité avec laquelle Struts a été intégrée le rend compatible avec tout ce que fait Rails, ainsi que tout ce dont une application de bureau aurait besoin. Malheureusement, la montagne de configuration qui permet cette flexibilité est un énorme défi pour quelqu'un qui n'a besoin que d'écrire une application Web ou simplement une application de bureau.

J'ai travaillé quelque part pour passer à l'étape suivante et discuter de «Configuration sur code », mais après l'avoir vu aller à son extrême logique, le résultat est que la configuration devient un nouveau langage de codage. C'était un jeu de passe-partout où la complexité se déplaçait sans être apprivoisée de manière significative. Et cela m'a permis d'apprécier tous les contrôles de type et autres filets de sécurité qu'un langage de programmation bien conçu dispose. Un format de fichier de configuration à moitié cuit qui explose sans message d’erreur si vous ajoutez un espace ou une apostrophe n’est PAS une amélioration par rapport à un langage de programmation de qualité qui possède des suites d’outils d’édition et un compilateur de qualité écrit pour celui-ci.

Je ne peux pas imaginer que des valeurs par défaut raisonnables violent les principes théoriques d'extensibilité et de modularité. Un programmeur Ruby / Rails préfèrerait se lancer dans un poker torride plutôt que de passer à un framework tel que Struts 1, dans lequel toutes les configurations sont définies explicitement dans plusieurs fichiers XML. Je ne discute pas de Rails vs. Struts EN GÉNÉRAL, mais cette convention peut être un gain de productivité énorme. Ces deux technologies constituent la comparaison la plus extrême que j'ai rencontrée dans le monde réel.

Si vous travaillez en Java, consultez le document "Effective Java" de Joshua Bloch, élément 2: "Envisagez un générateur confronté à de nombreux paramètres de constructeur", pages 11-16. Dans la plupart des cas, certains paramètres (configuration) sont requis, et certains sont facultatifs. L'idée de base est d'exiger uniquement la configuration nécessaire et de faire en sorte que l'utilisateur (qui pourrait être un autre programme) spécifie des options supplémentaires en fonction des besoins. J'ai nettoyé un tas de code avec ce motif il y a un mois et il scintille positivement.

En d'autres termes, la fonctionnalité de l'application n'est pas complètement expliquée par son propre code, mais aussi par la documentation du framework.

La fonctionnalité d'une application qui utilise un framework dépend toujours du framework, la convention sur la configuration ne fait aucune différence à cet égard.

D'après mon expérience, la convention sur la configuration rend non seulement le code plus lisible, mais réduit également la possibilité d'introduire des bogues subtils (en particulier des bogues de type copier-coller).

Par exemple, supposons que dans un framework A, event FooBardéclenche un appel à handleFooBar. Dans un autre cadre B, cette corrélation est configurée quelque part dans un fichier XML.

Donc, en A, c'est simplement

handleFooBar() {
   ...
}

et à moins que FooBar soit mal orthographié, il sera appelé à chaque fois que FooBar se produit.

En B, c'est encore

handleFooBar() {
   ...
}

mais aussi

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

Avec des centaines de choses à configurer de cette façon, il est trop facile de créer accidentellement un bogue subtil comme

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

parce qu'après le copier-coller, nous avons seulement changé <type>mais nous avons oublié de changer <handler>.

Étant donné que ces fichiers de configuration sont volumineux et monotones, il est moins probable que quelqu'un trouve le bogue par correction d'épreuves qu'il le trouverait dans le code de programme réel.

Cela enfreint peut-être peu de principes, mais en même temps, il obéit à l'un des principes de conception les plus fondamentaux, SRP (Single Responsibility Principle).