Trop de couches d'indirection, est-ce trop?

Question

Je me demandais juste si ce serait de nombreuses couches d'indirection?

Alt text http://img244.imageshack.us/img244/7371/classdiagram1.jpg

j'essayer de faire un peu d'expliquer. L'idée est que je construis une API au-dessus d'un objet COM qui expose uniquement les méthodes Do et Eval. Auparavant, je viens de passer un IComObject dans la classe Table et de travailler directement contre cela. Cela signifie que lorsque j'essaie de tester la classe Table, je me moque de IComObject et je m'inquiète des commandes envoyées à l'objet COM dans ma table classe. L'idée de base est que j'ai des coureurs de commande chargés d'appeler les bonnes commandes dans l'objet COM, et que l'objet Table (et autres) parle aux coureurs de la commande, sans avoir à se soucier des commandes en cours d'exécution . Puis dans mes tests je peux faire ceci:

Mock<TableCommandRunner> mockrunner = new Mock<TableCommandRunner>(); 
mockrunner.Setup(run => run.getName("DummyTable")).Returns("FakeName"); 

Table table = new Table("DummyTable"); 
//Table.Name just calls commandrunner.getName 
Assert.Equal(table.Name,"FakeName"); 

Y a-t-il trop de couches d'indirection ou est-ce que ce serait OK?

NOTE: Je vais avoir beaucoup plus de classes que Table, des choses comme Map, Window, Object, etc. qui parleraient toutes aux coureurs de commande.

Answer 1

Je ne suis pas vraiment sûr, mais pour moi, en cas de doute, j'aime toujours fournir des méthodes de raccourcis pratiques qui enveloppent ce genre d'abstraction.

Quelque chose comme

void runCommand(string cmd) // objects instantiated and used inside 

même si j'ai trop abstraction, il y a encore un moyen simple pour juste « faire bon sang ».

Answer 2

La question que vous devez vous poser est: est-ce que cette abstraction supplémentaire résout un problème que vous aviez avant de l'ajouter, et la complexité de l'abstraction est-elle acceptable pour vous? Quand faire abstraction est une décision assez subjective ... comme on le dit souvent, l'abstraction peut résoudre presque n'importe quel problème, mais au prix d'une plus grande complexité.

Si vous posez cette question, il semble que vous vous interrogez sur la valeur de la complexité supplémentaire que cette abstraction apporte à la table. Cela n'a pas l'air terriblement compliqué étant donné votre diagramme, et si cela résout effectivement un problème que vous aviez auparavant ... Je dirais qu'il va avec. En fin de compte, allez-y avec votre instinct ... abstrait si nécessaire, mais évitez-le si vous le pouvez.

Answer 3

Je ne pense pas que ce soit trop de niveaux d'abstraction. Votre solution me semble assez élégante parce que vous testez simplement que la classe Table appelle les bonnes fonctions de ComandRunner. Vous testez comment la classe Table gère le CommandRunner et vous avez supprimé toutes les complications des implémentations CommandRunner, y compris IComObject. C'est de cela que Mocking parle.