Je travaille sur un design, mais continue à frapper un barrage routier. J'ai une classe particulière (ModelDef) qui est essentiellement le propriétaire d'une arborescence de nœuds complexe construite en analysant un schéma XML (pensez DOM). Je veux suivre de bons principes de conception (SOLID) et m'assurer que le système résultant est facilement testable. J'ai bien l'intention d'utiliser DI pour passer des dépendances dans le constructeur de ModelDef (afin que celles-ci puissent facilement être échangées, si besoin est, pendant les tests).
Ce avec quoi je lutte, cependant, c'est la création de l'arborescence des nœuds. Cet arbre va être entièrement constitué d'objets simples de "valeur" qui n'auront pas besoin d'être testés indépendamment. (Cependant, je peux toujours passer une usine abstraite dans ModelDef pour aider à la création de ces objets.)
Mais je continue de lire qu'un constructeur ne devrait pas faire de vrai travail (par exemple Flaw: Constructor does Real Work ). Cela est parfaitement logique pour moi si le «vrai travail» signifie la construction d'objets dépendants de poids lourds que l'on pourrait plus tard vouloir extraire pour les tester. (Ceux-ci doivent être transmis via DI.)
Mais qu'en est-il des objets de valeur légers tels que cet arbre de nœuds? L'arbre doit être créé quelque part, non? Pourquoi pas via le constructeur de ModelDef (en utilisant, par exemple, une méthode buildNodeTree ())?
Je ne veux pas vraiment créer l'arborescence des nœuds en dehors de ModelDef, puis la transmettre (via le constructeur DI), car la création de l'arborescence des nœuds en analysant le schéma nécessite une quantité importante de code complexe - du code qui doit être soigneusement testé . Je ne veux pas le reléguer au code "glue" (qui devrait être relativement trivial et ne sera probablement pas testé directement).
J'ai pensé à mettre le code pour créer l'arborescence des nœuds dans un objet "builder" séparé, mais j'hésite à l'appeler un "builder", car il ne correspond pas vraiment au modèle Builder (qui semble plus soucieux d'éliminer le télescopage constructeurs). Mais même si je l'ai appelé quelque chose de différent (par exemple NodeTreeConstructor), cela ressemble toujours à un peu un hack juste pour éviter que le constructeur ModelDef construise l'arborescence des nœuds. Il doit être construit quelque part; pourquoi pas dans l'objet qui va le posséder?