Quels modèles de conception peuvent être appliqués au problème des paramètres de configuration?
Dans les produits logiciels volumineux et complexes, la gestion des paramètres configurables devient un problème majeur. J'ai vu deux approches du problème:
- chaque composant du système charge sa propre configuration à partir des fichiers de configuration ou des paramètres de registre.
- avoir une classe de chargeur de paramètres qui charge tous les paramètres système configurables et demander à chaque composant d'interroger le chargeur de paramètres pour ses paramètres.
Ces deux approches me semblent fausses.
Y a-t-il des modèles de conception qui pourraient être utilisés pour simplifier le problème? Peut-être quelque chose qui tirerait parti de la technique d'injection de dépendance.
Je préfère créer une interface pour définir la requête, le chargement et l'enregistrement. En utilisant l'injection de dépendances, je peux l'injecter dans chaque composant qui en a besoin.
Cela permet une flexibilité en termes de remplacement de la stratégie de configuration, et donne une base commune pour que tout fonctionne. Je préfère cela à un seul "chargeur de paramètres" global (votre option 2), d'autant plus que je peux remplacer le mécanisme de configuration d'un seul composant si j'ai absolument besoin de le faire.
Je travaille actuellement sur un système où la configuration est gérée par un objet singleton global qui conserve une carte des clés de configuration aux valeurs. En général, je souhaite que cela n'ait pas été fait de cette façon car cela peut provoquer des goulots d'étranglement de concurrence dans le système et c'est bâclé pour les tests unitaires, etc.
Je pense que Reed Copsey a le droit (je l'ai voté), mais je recommanderais certainement de lire le grand article de Martin Fowler sur l'injection de dépendance:
http://martinfowler.com/articles/injection.html
Un petit addenda aussi ... si vous voulez faire des tests unitaires de type objet simulé, l'injection de dépendance est certainement la voie à suivre.
Que dis-tu de ça. Vous définissez une interface configurable avec une seule méthode configure (configuration). L'argument de configuration est simplement une table de hachage qui associe les noms des paramètres de configuration à leurs valeurs.
Les objets racine peuvent créer une table de hachage de configuration comme ils le souhaitent (ex: en la lisant dans un fichier de configuration). Cette table de hachage peut contenir des paramètres de configuration pour l'iselft d'objet racine, ainsi que tout paramètre que l'un de ses composants, sous-composants, sous-sous-composants (etc.) pourrait utiliser.
L'objet racine appelle ensuite configure (configuration) sur tous ses composants configurables.