間接層太多了，這太多了嗎？

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

我嘗試做解釋的一點點。這個想法是，我正在COM對象的頂部創建一個API，它只暴露了Do和Eval方法。

此前，我剛剛將一個IComObject傳遞到Table類中，並直接針對該類，但這意味着當我嘗試和測試Table類時，我模擬了IComObject，並擔心發送到我表中的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");

是否有太多的間接層，或者這是行嗎？

注：我將有更多的類然後只是表，像地圖，窗口，對象等，這些都會與命令跑步者交談。

來源

2009-06-09 Nathan W

我認爲這個問題有點主觀，也許考慮重新措詞它。 – 2010-11-04 11:32:30

圖像鏈接已損壞。 – 2016-12-14 16:23:51

我不太確定，但對於我來說，如果有疑問，我總是喜歡提供包裝這種抽象的快捷方便的方法。

喜歡的東西

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

所以，即使我有太多的抽象，還是有直接的方式只是「做該死」。

來源

2009-06-09 07:24:15 hasen

你需要問的問題是，這個額外的抽象解決了你在添加它之前所遇到的一些問題，並且是你可以接受的抽象的複雜性？何時抽象是一個非常主觀的決定......正如人們常說的那樣，抽象可以解決幾乎任何問題，但代價是更復雜。

如果您提出這個問題，似乎您質疑這種抽象帶來的額外複雜性的價值。根據你的圖表，它看起來並不複雜，如果它確實解決了你之前遇到的問題......我會說去吧。

最終，用你的直覺行事......必要時抽象，但如果可以的話就避免。

來源

2009-06-09 07:25:52 jrista

我不認爲它的抽象層次太多。您的解決方案對我來說看起來很優雅，因爲您只是測試Table類調用正確的ComandRunner函數。您正在測試Table類如何處理CommandRunner，並且已經刪除了包括IComObject在內的所有CommandRunner實現的複雜性。這就是Mocking的全部內容。

來源

2009-06-09 16:26:11

間接層太多了，這太多了嗎？

回答

相關問題