Одиночная ответственность (СРП) и Скажи не спрашивай (ТДА)?

Question

Я понимаю, что многие принципы дизайна в некоторых случаях противоречат друг другу. Итак, мы должны взвесить их и посмотреть, какой из них более выгоден. До сих пор я знал о принципе SRP и делал много проектов исключительно на основе этого, но внутренне я чувствовал себя иногда неправильно, следуя этому принципу. Теперь я узнал о TDA, мои чувства получили больше поддержки с этим:)

SRP:- Объект должен беспокоиться о собственной заботе, а не о ком-либо

TDA:- Поведение (которое зависит только от состояния объекта) должно храниться внутри самого объекта

Пример:- У меня есть разные формы, такие как прямоугольник, квадрат, круг и т. Д. Теперь мне нужно вычислить площадь.

Мой дизайн до сих пор:- Я следовал SRP, где у меня был класс AreaCalculatorService, который будет запрашивать состояние формы и вычислять площадь. Причиной этого дизайна было то, что форма не должна беспокоиться о расчете площади, так как это не форма ответственности. Но в идеале я привык думать, что код вычисления области должен находиться под каждой формой, как если бы вниз по линии, если появляется новая форма, я должен изменить класс AreaCalculatorService (который нарушает принцип "Открыть для расширения и закрыть для модификации" (OECM)). Но всегда отдавал предпочтение СРП. Это кажется неправильным

Миф разрушен (по крайней мере, мой):- С TDA, похоже, мое чувство было правильным, когда я не должен спрашивать о состоянии объекта, но сказать форму, чтобы вычислить его площадь. Хотя это нарушит принцип SRP, но будет поддерживать принцип OECM. Как я уже говорил, принципы проектирования иногда конфликтуют друг с другом, но я считаю, что когда поведение полностью зависит от состояния объекта, поведение и состояние должны быть вместе.

Другой пример:- скажем, мне нужно рассчитать зарплату всех отделов всех сотрудников в организации, тогда мы должны следовать SRP, где SalaryCalculatorService будет зависеть от отдела и сотрудников.

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

Дайте мне знать, если моя интерпретация обоих этих принципов верна или нет, где я должен следовать TDA в первом случае, но SRP во втором?

Answer 1

Я думаю, что ваше понимание TDA является правильным. Проблема с SRP, по моему опыту, это принцип SOLID, наиболее неправильно понятый. SRP говорит, что один класс должен иметь только одну причину для изменения. Часть "причина изменения" часто путают с "она должна иметь только одну ответственность", поэтому "она должна делать только одну вещь". Нет, это не так.
"Причина изменения" полностью зависит от контекста приложения, в котором находится класс. В частности, это зависит от действующих лиц, которые взаимодействуют с программным обеспечением и которые в будущем могли бы запрашивать изменения.
Актерами могут быть: клиент, который платит за программное обеспечение, обычные пользователи и некоторые суперпользователи. Администраторы баз данных, которые будут управлять базой данных приложения или ИТ-отделом, который обрабатывает оборудование, на котором выполняется приложение. После того, как вы перечислили всех участников вокруг вашего программного обеспечения, чтобы следовать тому, что говорит SRP, вы должны написать свой класс таким образом, чтобы на него была только одна ответственность, поэтому только запросы от одного субъекта могут потребовать некоторых изменений в вашем классе.,
Итак, я думаю, что вы должны следовать TDA, помещая данные и поведения, которые используют эти данные внутри одного и того же объекта. Таким образом, вы можете управлять отношениями между объектами, сообщая им, что делать, вместо того, чтобы запрашивать данные, уменьшая связь и достигая лучшей инкапсуляции.
SRP, как объяснялось выше, поможет вам решить, какие виды поведения относятся к одному объекту, а не к другому.