Когда я помещаю логику в класс в отличие от передачи класса в служебный класс?

Question

Когда у меня есть ряд процессов, которые похожи по своей природе, но работают над объектами немного разных типов, я должен объединить тип работы в одном классе утилит или поставить функциональность непосредственно на каждый объект, который потребуется использовать функционал?

Меня не интересует конкретный случай как таковой, но мне наиболее интересно, какие факторы влияют на это решение.

Answer 1

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

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

, если, с другой стороныФункциональность отличается тем, что в вашем служебном классе вам понадобится большой оператор switch / case для размещения различных типов объектов, возможно, вы захотите реализовать его в самих объектах.

Answer 2

У вас есть два подхода к вашей проблеме: один - использовать универсальное программирование (горизонтальный полиморфизм) или атаковать его, используя более традиционную реализацию на основе вертикальной иерархии.

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

Это, например, случай со списком, словарем и всеми классами в пространстве имен System.Collections.Generic, которые в итоге заменили соответствующие им неуниверсальные аналоги ранних версий .NET.

С другой стороны, опять же из мира .NET мы можем использовать в качестве примера вертикальной иерархии класс UserControl, который наследуется от ContainerControl и служит основой для других элементов управления, специализирующих его поведение с использованием его виртуальных методов....

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