Слишком много слоев косвенности, это слишком много?

Question

Мне просто интересно, если это будет много слоев косвенности?

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

Я пытаюсь немного объяснить. Идея состоит в том, что я создаю API поверх COM-объекта, который предоставляет только методы 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");

Слишком много слоев косвенности или все будет в порядке?

ПРИМЕЧАНИЕ: у меня будет намного больше классов, чем просто Table, такие вещи, как Map, Window, Object и т. Д., Которые будут общаться с участниками команды.

Answer 1

Вопрос, который вам нужно задать, заключается в том, решает ли эта дополнительная абстракция какую-то проблему, с которой вы столкнулись до ее добавления, и приемлема ли сложность абстракции для вас? Когда абстрагирование - это довольно субъективное решение... как часто говорят, абстрагирование может решить практически любую проблему, но за счет большей сложности.

Если вы задаете этот вопрос, кажется, что вы ставите под сомнение ценность дополнительной сложности, которую эта абстракция вносит в таблицу. Это не выглядит ужасно сложным, учитывая вашу диаграмму, и если это действительно решит проблему, с которой вы сталкивались раньше... Я бы сказал, продолжайте.

В конечном счете, следуйте своим инстинктам... абстрактно, когда это необходимо, но избегайте этого, если можете.

Answer 2

Я не думаю, что это слишком много уровней абстракции. Ваше решение выглядит довольно элегантно для меня, потому что вы просто проверяете, что класс Table вызывает правильные функции ComandRunner. Вы проверяете, как класс Table взаимодействует с CommandRunner, и вы удалили все сложности реализаций CommandRunner, включая IComObject. В этом суть насмешки.

Answer 3

Я не совсем уверен, но для меня, когда есть сомнения, я всегда хотел бы предоставить удобные методы ярлыков, которые оборачивают этот вид абстракции.

Что-то вроде

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

так что даже если у меня слишком много абстракций, все равно есть простой способ просто "сделать это, черт побери".