1

これが何層もの間接化になるのではないかと思っていました。

代替テキスト http://img244.imageshack.us/img244/7371/classdiagram1.jpg

私は少し説明しようとします。アイデアは、Do および Eval メソッドのみを公開する COM オブジェクトの上に API を構築しているということです。

以前は、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");

間接的な層が多すぎますか、それとも問題ありませんか?

注: テーブルだけでなく、Map、Window、Object など、すべてコマンド ランナーと通信するクラスがさらに多くなります。

4

3 に答える 3

7

質問する必要があるのは、この追加の抽象化によって、追加する前に抱えていた問題が解決されるか、また、抽象化の複雑さが受け入れられるかということです。いつ抽象化するかはかなり主観的な決定です...よく言われるように、抽象化はほとんどすべての問題を解決できますが、複雑さが増すという犠牲を払います。

この質問をしている場合、この抽象化がテーブルにもたらす追加の複雑さの価値を疑問視しているようです。あなたのダイアグラムを考えると、それほど複雑に見えません。以前に抱えていた問題が実際に解決されるのであれば、私はそれでいいと思います。

最終的には、直感に従ってください...必要に応じて抽象化しますが、できれば避けてください。

于 2009-06-09T07:25:52.477 に答える
2

抽象化のレベルが多すぎるとは思いません。Table クラスが適切な ComandRunner 関数を呼び出すことを単にテストしているだけなので、あなたのソリューションは私には非常にエレガントに見えます。Table クラスが CommandRunner を処理する方法をテストしており、IComObject を含む CommandRunner 実装のすべての複雑さを取り除きました。これがモッキングのすべてです。

于 2009-06-09T16:26:11.493 に答える
0

よくわかりませんが、私にとっては、疑わしい場合は、この種の抽象化をラップするショートカットの便利なメソッドを常に提供するのが好きです。

何かのようなもの

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

抽象化が多すぎる場合でも、「くそったれ」だけの簡単な方法があります。

于 2009-06-09T07:24:15.710 に答える