Как применить принцип единой ответственности к классу обслуживания

Question

Предположим, мы разрабатываем класс UserServiceImpl, который выполняет операции CRUD (создание, чтение, обновление и удаление). На мой взгляд, Create, Read, Update и Delete - четыре причины для изменения класса. Этот класс нарушает принцип единой ответственности? Если это нарушает, тогда мы должны иметь четыре класса, такие как CreateUserServiceImpl, ReadUserServiceImpl, UpdateUserServiceImpl и DeleteUserServiceImpl. Разве не лишнее иметь много классы?

Предположим, я определил 4 интерфейса каждый для операций создания, чтения, обновления и удаления, и мой класс обслуживания реализует все четыре интерфейса. Теперь я могу иметь только один класс реализации, но, разделяя их интерфейсы, я отделил понятия как Что касается остальной части заявки. Это правильный путь или вы видите некоторые проблемы в этом?

Answer 1

Это то, что мне нравится в шаблонах и принципах - они представляют собой единый способ для всех не согласиться с дизайном программного обеспечения и согласиться с ним: -)

Моя точка зрения заключается в том, чтобы создать класс любым способом, который сделает его пригодным для использования и легким для понимания классом - в зависимости от сложности и контекста, в котором живет класс. С простой реализацией и контекстом подойдет один класс. Вы могли бы сказать, что он придерживается SRP, потому что он отвечает за управление операциями CRUD. Но если реализация сложна, или есть много общего кода, который будет подходящим для размещения в абстрактном родительском классе, тогда, возможно, 4 отдельных класса, по одному для каждой операции CRUD, имеют больше смысла. все дело в том, как ты на это смотришь.

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

Answer 2

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

Почему?

Если у меня есть Stack класс, есть ли Push и Pop причины для изменения класса?

Я так не думаю. Это две стандартные операции, которые люди выполняют со стеком. То же самое с CRUD, это простой, хорошо известный набор операций над хранилищем данных.

Теперь ваша базовая технология хранения данных является причиной изменения вашего класса. То есть, если ваша реализация CRUD жестко запрограммирована для работы только с конкретным экземпляром базы данных MS SQL 6.0, то вы нарушаете SRP, и этот класс будет непросто повторно использовать или расширять.

Что касается 4 интерфейсов, то это ближе к другому принципу SOLID, ISP , и необходимость здесь определяется моделями использования вашего хранилища данных. Например, если некоторым классам потребуется только чтение из хранилища данных, имеет смысл извлечь интерфейс с помощью только метода Read и запросить этот интерфейс в качестве аргумента для таких методов. Разделяя этот интерфейс, вы можете позже создать его отдельную реализацию. Кто знает, может быть, для клиентов только для чтения вы можете выполнить более оптимизированный запрос или использовать кэш памяти, но если нет - вы можете просто передать им экземпляр хранилища данных по умолчанию, реализующий этот интерфейс.

Answer 3

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