Как применить Единственный Принцип Ответственности к классу обслуживания
Предположим, что мы разрабатываем класс UserServiceImpl, который делает CRUD (Создайте, Чтение, Обновление, и Удалите), операции. По моему мнению, Создайте, Чтение, Обновление, и Удалите, четыре причины класса для изменения. Этот класс нарушает Единственный Принцип Ответственности? Если это нарушает, то должны мы иметь четыре класса как CreateUserServiceImpl, ReadUserServiceImpl, UpdateUserServiceImpl, и DeleteUserServiceImpl. Разве это не излишество, чтобы иметь много классов?
Предположим, что я определяю 4 интерфейса, каждый для создает, считал, обновляет и удаляет операции, и мой класс обслуживания реализует все четыре интерфейса. Теперь у меня может только быть единственный класс реализации, но путем разделения их интерфейсов я отделил понятия, что касается отдыха приложения. Действительно ли это - правильный путь, или Вы видите некоторые проблемы в нем?
2 ответа
Вот что мне нравится в шаблонах и принципах - они являются последовательным способом для всех не соглашаться по поводу дизайна программного обеспечения, а также соглашаться: -)
Мои view будет строить класс таким образом, чтобы сделать его удобным и легким для понимания классом - в зависимости от сложности и контекста, в котором живет класс. С простой реализацией и контекстом подойдет один класс. Можно сказать, что он соответствует SRP, потому что он отвечает за управление операциями CRUD. Но если реализация сложна или есть много общего кода, который можно было бы разместить в абстрактном родительском классе, то, возможно, 4 отдельных класса, по одному для каждой операции CRUD, имеют больше смысла. все дело в том, как вы на это смотрите.
Шаблоны и принципы - замечательные вещи, но их неправильное использование может сделать простую задачу столь же сложной, как и их отсутствие.
Принцип единой ответственности не нарушается до тех пор, пока служба не будет отвечать за услуги передачи данных одного типа или бизнес-информацию.