Отдельный класс против метода

Question

Быстрый дизайн вопрос.

В ClassA есть метод DoSomething (args)

В DoSomething (), прежде чем он сможет что-то сделать, ему нужно выполнить некоторую подготовительную работу с аргументами. Я считаю, что это должно быть заключено в ClassA (в отличие от выполнения подготовительной работы снаружи и передачи ее внутрь), поскольку ничто иное не должно знать, что эта подготовительная работа требуется для DoSomething.

Тем не менее, именно здесь и находится настоящий подготовительный рабочий код, который заставляет меня задуматься.

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

У меня есть догадка, что я должен создать новый класс ListOfStuff, который принимает аргументы в своем конструкторе и помещает эту подготовительную работу здесь.

С точки зрения TDD, я думаю, что это правильный выбор. Затем мы можем выполнить модульный тест ListOfStuff, пока наше сердце будет довольным. Если бы мы поместили подготовительную работу в закрытый метод ClassA, мы бы смогли косвенно протестировать ее только путем тестирования DoSomething ().

Но это перебор? С тех пор, как был принят подход TDD и DI, я видел количество классов, которые я пишу многократно - стоит ли мне волноваться?

* * 1016 Та.

Answer 1

Здесь есть пара эвристик.

1. Есть ли в этом классе состояние, выживает от вызова к вызов? Получается ли эта подготовительная работа? сделано каждый раз, когда вам нужно doSomething (), или это сделано и спасен? Если так, то это доказывает класс.
2. Это вычисление должно произойти в более чем одном месте? Если так, что доказывает класс.
3. Может подробности реализация doSomething () метод или подготовительная работа для это, изменить, не влияя на вмещающий класс? Если так, то это доказывает для класса.

Ну, три эвристики. Никто не ожидает испанской инквизиции.

Answer 2

Какая самая простая вещь, которая могла бы сработать? Это мантра TDD. Не пытайтесь думать слишком далеко вперед. Если придет время создать вспомогательный класс, вы об этом узнаете, потому что вы будете выполнять все виды связанной работы с несколькими методами в других классах. До тех пор, делайте работу в вашем методе. Если это делает метод слишком длинным или громоздким для чтения, извлеките работу в свой собственный метод. Этот метод также может быть проверен на ваше усмотрение без необходимости в другом классе.

Answer 3

Определенно поместите его в новый класс. Это называется разделением интересов. Вы не хотите перегружать класс и заставлять его делать всякие другие вещи. Это потому, что ваш класс не сможет быть использован где-либо еще, поскольку он так специфичен для одной вещи.

Поместите его в класс, а затем используйте этот класс в другом месте. В противном случае вам придется писать это снова и снова в будущем.

Чтобы сделать его расширяемым и иметь возможность передавать все виды различных алгоритмов, шаблон проектирования, который вам нужен, - это шаблон Strategy . Но это на будущее ...

Answer 4

SoC действителен только в том случае, если рассматриваемая «забота» не имеет ничего общего с классом, или вы находите классы, разделяющие эту «заботу» (иначе говоря, нарушающие DRY). В вашем случае кажется, что код присущ классу - так что, возможно, функция private будет более подходящей.

Как сказал выше tvanfosson, вам нужно сбалансировать SoC с YAGNI. Лично я думаю, что вы, возможно, обдумываете это преждевременно (я знаю! Я тоже так делаю постоянно).

Answer 5

С момента принятия TDD и DI подход, я видел количество классы, которые я пишу, умножаются - должны Я беспокоюсь?

Если ваша цель - процедурное программирование, да. Но так как вы почти наверняка хотите работать в режиме OO, нет.

Большинство людей используют слишком мало типов, тратят слишком мало времени на размышления о дизайне ОО.

Ваши вопросы об ответственности класса отражают взросление мышления (imho).

Answer 6

Ваш дизайн объектной модели должен рассматриваться сам по себе, а не в контексте вашей стратегии развития. Если создание ListOFStuff и переход к DoSomething действительно таковы, как объектная модель лучше всего сочетается, сделайте это независимо от вашей стратегии разработки .

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

Надеюсь, это поможет!