Принцип единой ответственности (SRP) и мой класс обслуживания
Я имею YoutubeVideoService класс, который выполняет операции CRUD(создание, чтение, обновление и удаление). На мой взгляд, Create, Read, Update и Delete являются четырьмя причинами для изменения класса. Этот класс нарушает принцип единой ответственности?
Если это нарушает, то мы должны иметь четыре класса, как CreateYoutubeVideoService, ReadYoutubeVideoService, UpdateYoutubeVideoService а также DeleteYoutubeVideoService, Разве не слишком много занятий?
2 ответа
Я думаю, что вы принимаете принцип единого повторения немного до крайности на уровне класса, не принимая во внимание сплоченность.
Если вы следуете по этому пути, вы могли бы оправдать наличие множества классов одним или двумя методами, что, в свою очередь, увеличило бы количество зависимостей от неба.
Я думаю, что дух SRP упрощает столько, сколько вы можете, но не больше.
Хороший способ измерить согласованность с принципом единой ответственности - подумать о том, сколько причин изменить этот класс. Если вы можете придумать более одной причины для изменения, возможно, это нарушает SRP.
Единственная причина для изменения класса CRUD, подобного этому, - это изменение структуры лежащих в основе данных. Так что это уважает SRP.
С другой стороны, если у вас в этом классе есть какие-либо другие операции (например, проверка длины или типа видео перед его вставкой), это нарушит SRP, поскольку оно может изменяться независимо от уровня постоянства.
SRP не является догмой, когда следуя принципам SOLID, мы всегда должны быть осторожны, чтобы не вводить сложность игл. Согласно шедевру Боба Мартина, говоря о том, когда две обязанности должны быть разделены:
Если, с другой стороны, приложение не изменяется таким образом, что эти две обязанности меняются в разное время, нет необходимости разделять их. Действительно, их разделение пахнет ненужной сложностью. (…) Не имеет смысла применять SRP (или любой другой принцип в этом отношении), если нет симптомов.
Как долго должен быть метод? Можно сказать, что нет причин иметь более 2 строк. Но это, конечно, излишне в некоторых ситуациях. То же самое с SRP - вы должны решить, когда достаточно. CRUD выглядит как сплоченный набор операций, которые идеально подходят для одного класса, потому что они работают с данными того же типа.
Служебные классы - убийцы SRP. По определению они представляют собой совокупность операций, что противоречит SRP. Часто для одного метода службы требуется некоторая зависимость, и все другие методы могут вообще не заботиться, а затем, когда зависимости каждого такого метода умножаются, это приводит к беспорядку. Менеджер, Сервис, иногда репозиторий - эти шаблоны просто плохи с точки зрения зависимостей. В мире Commands/Queries/Requests у вас будут эти 3 команды и запрос, просто сгруппированные в домен / каталог. Это приводит к более чистому, компактному, удобному для чтения и расширяемому коду. Также для более чистых процессов.