间接层太多了，是不是太多了？

Question

我只是想知道这是不是会有很多层的间接性？

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

我试着做一点解释。我的想法是在一个只公开Do和Eval方法的COM对象之上构建一个API。

以前，我只是向Table类传递了一个IComObject，并直接对其进行了处理，然而，这意味着当我尝试和测试Table类时，我会模拟IComObject，并担心命令会被发送到我的Table类中的COM对象。

基本思想是，我让命令运行器负责调用COM对象中的正确命令，而Table (和其他)对象只与命令运行器通信，而不必担心正在执行的命令。然后在我的测试中，我可以这样做：

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");

是否有太多的间接层，或者这是可以的？

注意:我将拥有比Table多得多的类，比如Map、Window、Object等，它们都可以与命令运行器通信。

Answer 1

你需要问的问题是，这个额外的抽象是否解决了你在添加它之前遇到的一些问题，以及抽象的复杂性对你来说是可接受的吗？当抽象是一个非常主观的decision...as常说，抽象可以解决几乎任何问题，但以更大的复杂性为代价。

如果你在问这个问题，你似乎是在质疑这个抽象给表带来的额外复杂性的价值。考虑到你的图表，它看起来并不是特别复杂，如果它确实解决了你之前遇到的问题……我会说，就这么做吧。

最后，在必要时使用instincts...abstract，但如果可以避免使用它。

Answer 2

我不认为它有太多的抽象层次。在我看来，您的解决方案非常优雅，因为您只是在测试Table类是否调用了正确的ComandRunner函数。您正在测试Table类如何处理CommandRunner，并且您已经消除了CommandRunner实现的所有复杂性，包括IComObject。这就是Mocking的全部内容。

Answer 3

我不是很确定，但对我来说，当我有疑问时，我总是喜欢提供快捷方便的方法来包装这种抽象。

就像这样

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

因此，即使我有太多的抽象概念，仍然有一种直接的方法来“去做该死的”。