Comments 12
https://habr.com/ru/articles/465507/
SRP - это не когда у тебя один класс имеет только один метод.
Реализация принципа единственной ответственности на Python
Типа есть принципиальная разница реализации этого принципа в зависимости от языка? Принцып как-то по другому действует для классов написанных в С++ или в Java?
Это реклама Python?
сомнительный способ, осталось только все классы по разным файлам распихать
Периодически попадаются статьи по SOLID и примерно понимал этот принцип как вы описали в статье (только конечно не ограничиваясь одной функцией в классе). Но недвано добрался до первоисточника, в котором написано совсем иное и был крайне удивлен как много опытных программистов ошибаются в понимании принципа единой ответственности.
Цитата из книги: Роберт Мартин "Чистая архитектура. Искусство разработки программного обеспечения"
Hidden text
Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что‑то дно. Самое интересное, что такой принцип действительно существует.
Он гласит: функция должна делать что‑то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Традиционно принцип единственной ответственности описывался так: Модуль должен иметь одну и только одну причину для изменения. Программное обеспечение изменяется для удовлетворения нужд пользователей и заинтересованных лиц.
Пользователи и заинтересованные лица как раз и есть та самая «причина для изменения», о которой говорит принцип. Фактически принцип можно перефразировать так: Модуль должен отвечать за одного пользователя или заинтересованное лицо. и только за одного К сожалению, слова «пользователь» и «заинтересованное лицо» не совсем правильно использовать здесь, потому что одного и того же изменения системы могут желать несколько пользователей или заинтересованных лиц.
Более правильным выглядит понятие группы, состоящей из одного или нескольких лиц, желающих данного изменения. Мы будем называть такие группы акторами (actor).
Более того, я когда читал про solid, всегда вызывало отторжение. Всегда было чувство, что это модная чепуха. Много противоречий, разнотолков у авторов. Вплоть до того, что в классах оставляли только один метод invoke.
Потом я прочитал Мартина, дядю Боба. А у него все просто и понятно. SOLID - попытка бездумной формализации в нескольких предложениях философии Мартина. Имхо - довольно неудачная.
Кстати, и Spring необходимо изучать только после того, как прочитаешь "Желтую книгу". Иначе он все равно вызовет у тебя отторжение.
Статья хорошая. Однако данный пример может ложно навести на мысль, что необходимо разбивать на классы с одним-единственным методом. А это не так, согласно Мартину.
Предлагаю или явно это указать, либо сделать классы, к примеру не Saver, а DataSource и определить в нем методы Save и Find.
Классы в python - это оверхед на ram. Нафиг ООП.
Солидный код - плохой код.
Солидный сервис - хороший сервис
Классы в python - это оверхед на ram. Нафиг ООП.
Классы это оверхед по памяти в любом языке.
ООП это удобный инструмент со своими ограничениями.
Солидный код - плохой код.
Если вы про код использующий SOLID принципы, это не так. Под копотом там достаточно сильные и универсальные идеи. Не везде они применими и не всякий код который который пытается быть SOLID им является.
Солидный сервис - хороший сервис
Не знаком с этим термином.
Реализация принципа единственной ответственности на Python