О чем на самом деле идет речь в single-responsibility principle?

Question

[ant123455432143]

Здравствуйте. До этого я почти везде читал, что SRP гласит, что

Модуль должен иметь одну и только одну причину для изменения.

Но в книге "Чистая архитектура" Роберта Мартина написано, что это мнение ошибочно, а SRP - это про то, что

Модуль должен отвечать за одного и только за одного актора.

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

Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP).
Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно.
Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.

Answer 1

[Eugene Usachev]

Я приведу обратный пример.

Вот есть у нас разработчик Вася. Он пишет embedded систему. И у него есть датчик, у которого есть встроенный таймер и который измеряет температуру. Ну Вася посмотрел на это и написал класс TimeTemp, который имеет поля ,относящиеся к таймеру, и имеет поля, относящиеся к температуре. То же самое с методами.

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

Потом пришёл Георгий и позаимствовал части кода с температурой.

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

Так же ошибку могли найти у Георгия, и тогда не факт, что в классе TimeTemp её сразу исправят. Это я молчу про то, что кода стало в два раза больше.

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

Answer 2

[Василий Банников]

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

Представим себе такой псевдокод:

конфиг = прочитать_конфиг_из_файла()
соединение = открыть_соединение_с_бд(конфиг.строка_подключения)
соединение.сохранить(данные)
соединение.закрыть()

Если у нас контекст, что это какой-то большое приложение, которое написано в ОО-стиле, то тут SRP явно нарушен:
Читать конфиг и открывать соединение нужно в другой функции и передавать в функцию по сохранению данных уже открытое соединение. Обработку ошибок при чтении файла или подключении стоит делать в другом месте.
Разделение этого когда повысить надёжность и облегчит разработку и поддержку, уменьшится дублирование кода, а местами код станет сильно проще.

С другой стороны, если у нас контекст - это просто небольшой скрипт, который делает бэкапы и он полностью самостоятелен, но нарушения нет - попытка разделить этот "скрипт" приведёт только к усложнению всего.

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