Single Responsibility Principle considered harmful
Привет!
Наткнулся тут на эту статью и чёт меня малёха бомбануло.
Теоретически, принцип (Single Responsibility Principle ) возможно хороший и правильный, ток с ним есть одна проблема - анкл Боб 20 (двадцать) лет его объясняет и ни как объяснить не может.
Мне удалось отследить следующую историю формулировок этого принципа самим Мартином:
- 19xx: чёт мне припоминается, что где-то он писал о то, что изначально публиковал эти принципы в каком-то журнале, но ссылок побырому я не нашёл
- 2003: "A class should have only one reason to change" - Agile Software Development, Principles, Patterns, and Practices
- 2008: "The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change" - Clean Code
- 2014: "Gather together the things that change for the same reasons. Separate those things that change for different reasons." - The Single Responsibility Principle
- 2018: "A module should be responsible to one, and only one, actor" - Clean Architecture
И тем не менее, в статье с которой меня бомбануло написано: "That class itself should do one thing".
По моим ощущениям "one thing" - это самая распространённая интерпретация SRP.
Всё бы ничего, но "thing" - понятие растяжимое.
Сортировка, например - одна вещь?
А если один метод в зависимости от размера входных данных использует разные алгоритмы?
Это всё ещё одна вещь или несколько?
А если код поддерживает сортировку массивов превышающих размер памяти и работает с диском соотвественно?
О размере вещей можно спорить бесконечно.
На небесах программисты только и говорят о том, сколько вещей делает тот или иной кусок кода.
Но даже чёрт с ней с вещью.
Сам анкл Боб путается в показаниях.
В одной из статей он пишет:
> "We do not mix business rules with GUI code".
Так-то всё правильно пишет - действительно не мешаем и это хорошо.
Ток изменения в требованиях от одного источника зачастую требует изменений и в гуе, и в правилах и в БД.
Т.е. эти штуки (для одной фичи) должны быть в одном месте.
В общем имхо, SRP - это хороший лозунг, который полезно знать и о котором стоит вспоминать, в третью очередь при анализе дизайна, но никак не основополагающий принцип дизайна.
И ещё не много хейта SOLID-а в целом:
1) https://www.youtube.com/watch?v=tMW08JkFrBA - доклад от крутого во всех смыслах мужика. Можно его прям по имени по ютубить и смотреть всё подряд. Настоятельно рекомендую.
2) https://www.tedinski.com/2019/04/02/solid-critique.html - пост от другого крутого мужика, который начал (и не осилил, похоже :( ) писать книгу примерно о том же, о чём пишу я:)
Но он осилил сильно больше чем я пока что, так что настоятельно рекомендую:)
3) https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong - просто слайды от неизвестного мужика, случайно попавшиеся под руку
На слайды из п. 3 Мартин даже ответил
#posts@ergonomic_code #solid@ergonomic_code
Привет!
Наткнулся тут на эту статью и чёт меня малёха бомбануло.
Теоретически, принцип (Single Responsibility Principle ) возможно хороший и правильный, ток с ним есть одна проблема - анкл Боб 20 (двадцать) лет его объясняет и ни как объяснить не может.
Мне удалось отследить следующую историю формулировок этого принципа самим Мартином:
- 19xx: чёт мне припоминается, что где-то он писал о то, что изначально публиковал эти принципы в каком-то журнале, но ссылок побырому я не нашёл
- 2003: "A class should have only one reason to change" - Agile Software Development, Principles, Patterns, and Practices
- 2008: "The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change" - Clean Code
- 2014: "Gather together the things that change for the same reasons. Separate those things that change for different reasons." - The Single Responsibility Principle
- 2018: "A module should be responsible to one, and only one, actor" - Clean Architecture
И тем не менее, в статье с которой меня бомбануло написано: "That class itself should do one thing".
По моим ощущениям "one thing" - это самая распространённая интерпретация SRP.
Всё бы ничего, но "thing" - понятие растяжимое.
Сортировка, например - одна вещь?
А если один метод в зависимости от размера входных данных использует разные алгоритмы?
Это всё ещё одна вещь или несколько?
А если код поддерживает сортировку массивов превышающих размер памяти и работает с диском соотвественно?
О размере вещей можно спорить бесконечно.
На небесах программисты только и говорят о том, сколько вещей делает тот или иной кусок кода.
Но даже чёрт с ней с вещью.
Сам анкл Боб путается в показаниях.
В одной из статей он пишет:
> "We do not mix business rules with GUI code".
Так-то всё правильно пишет - действительно не мешаем и это хорошо.
Ток изменения в требованиях от одного источника зачастую требует изменений и в гуе, и в правилах и в БД.
Т.е. эти штуки (для одной фичи) должны быть в одном месте.
В общем имхо, SRP - это хороший лозунг, который полезно знать и о котором стоит вспоминать, в третью очередь при анализе дизайна, но никак не основополагающий принцип дизайна.
И ещё не много хейта SOLID-а в целом:
1) https://www.youtube.com/watch?v=tMW08JkFrBA - доклад от крутого во всех смыслах мужика. Можно его прям по имени по ютубить и смотреть всё подряд. Настоятельно рекомендую.
2) https://www.tedinski.com/2019/04/02/solid-critique.html - пост от другого крутого мужика, который начал (и не осилил, похоже :( ) писать книгу примерно о том же, о чём пишу я:)
Но он осилил сильно больше чем я пока что, так что настоятельно рекомендую:)
3) https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong - просто слайды от неизвестного мужика, случайно попавшиеся под руку
На слайды из п. 3 Мартин даже ответил
#posts@ergonomic_code #solid@ergonomic_code
Tom McFarlin
What Are Programming Side Effects, Anyway? | Tom McFarlin
I previously discussed programming side effects in the context of PSR-1. But their importance extends beyond a single language and into general programming.
Привет!
Малёха солида вам в ленту с утра пораньше:)
Я уже как-то давал ссылку на критику SOLID-а.
А сегодня я подслушал в радиоте ссылку на более развёрнутый пост этого же мужика.
И там он даёт ссылку на критику своей критики:)
Когда-нибудь я обязательно накатаю собственный развёрнутый пост на эту тему:)
А пока у меня на подходе разгромный пост о JPA - уже отлёживается, завтра-после завтра опубликую:)
#posts@ergonomic_code #solid@ergonomic_code
Малёха солида вам в ленту с утра пораньше:)
Я уже как-то давал ссылку на критику SOLID-а.
А сегодня я подслушал в радиоте ссылку на более развёрнутый пост этого же мужика.
И там он даёт ссылку на критику своей критики:)
Когда-нибудь я обязательно накатаю собственный развёрнутый пост на эту тему:)
А пока у меня на подходе разгромный пост о JPA - уже отлёживается, завтра-после завтра опубликую:)
#posts@ergonomic_code #solid@ergonomic_code
Speaker Deck
Why Every Element of SOLID is Wrong
Five minute Ignite-style talk from PubConf London 2016
Привет!
Хотел написать небольшую заметку о SRP, OCP и дизайне типов и залип на 3 часа:)
Представляю вам пост ... <барабанная дробь>... Анкл Боб не всегда прав - критичное настроение всё ещё со мной:) В отпуск мне надо:)
#posts@ergonomic_code #solid@ergonomic_code
Хотел написать небольшую заметку о SRP, OCP и дизайне типов и залип на 3 часа:)
Представляю вам пост ... <барабанная дробь>... Анкл Боб не всегда прав - критичное настроение всё ещё со мной:) В отпуск мне надо:)
#posts@ergonomic_code #solid@ergonomic_code
Алексей Жидков
Анкл Боб не всегда прав - Алексей Жидков
Применение OCP в классическом виде может повлечь за собой нарушение SRP и повышенный риск регрессий.
Привет!
Экспозиция примеров нарушения LSP и их мотивации: https://github.com/spring-projects/spring-framework/issues/17787
> it would be easier to only maintain the additional feature of the "overridden" method.
> The easiest solution for us, if it were possible, would be to mark the PUT/POST/DELETE methods of the subclass as not accessible.
Наследование вообще плохая идея, а такое его использование - просто ужас
#posts@ergonomic_code #solid@ergonomic_code #spring@ergonomic_code
Экспозиция примеров нарушения LSP и их мотивации: https://github.com/spring-projects/spring-framework/issues/17787
> it would be easier to only maintain the additional feature of the "overridden" method.
> The easiest solution for us, if it were possible, would be to mark the PUT/POST/DELETE methods of the subclass as not accessible.
Наследование вообще плохая идея, а такое его использование - просто ужас
#posts@ergonomic_code #solid@ergonomic_code #spring@ergonomic_code
GitHub
Allow to disable method mappings from parent class [SPR-13195] · Issue #17787 · spring-projects/spring-framework
Thierry Messer opened SPR-13195 and commented If I extend a @Controller with the intention to replace the extended with the sub-classed one there is no possibility to disable a request mapping for ...
Привет!
Я два месяца возился с SOLID вообще и SRP в частности и наконец-то осилил первый пост про SRP.
И этот факт многое говорит о простоте и понятности этих штуковин:)
Чтобы следующие два месяца ждать было повеслее, раскажу о чём я хочу ещё написать:)
Про SRP можно написать ещё как минимум два поста:
- часто забываемая половина про объединение "штук" которые меняются вместе
- подробнее расписать, чем я предлагаю руководствоваться при разработке ПО.
И про остальные принципы мне тоже есть что сказать:)
Плюс на ближайшее время у меня есть идея двух небольших заметок:
- читайте свой код. О технике поиска проблем в дизайне через чтение кода как текста на естественном языке
- ещё чутка попинать JPA, за нарушение структуры поддерживаемых приложений, открытого ещё в 70ых
Далее у меня есть хвосты о которых я помню:
1) Дописать итог к серии постов о видах функций
2) Пост с критикой пакетирования по слоям
Плюс я сейчас читаю одну из самых крутых книг по проектированию поста в своей жизни - как дочитаю, обязательно напишу пост-обзор.
Но что, в каком порядке и в какие сроки я опубликую - я уже не берусь предсказывать, так что стей тюнед:)
#posts@ergonomic_code #solid@ergonomic_code
Я два месяца возился с SOLID вообще и SRP в частности и наконец-то осилил первый пост про SRP.
И этот факт многое говорит о простоте и понятности этих штуковин:)
Чтобы следующие два месяца ждать было повеслее, раскажу о чём я хочу ещё написать:)
Про SRP можно написать ещё как минимум два поста:
- часто забываемая половина про объединение "штук" которые меняются вместе
- подробнее расписать, чем я предлагаю руководствоваться при разработке ПО.
И про остальные принципы мне тоже есть что сказать:)
Плюс на ближайшее время у меня есть идея двух небольших заметок:
- читайте свой код. О технике поиска проблем в дизайне через чтение кода как текста на естественном языке
- ещё чутка попинать JPA, за нарушение структуры поддерживаемых приложений, открытого ещё в 70ых
Далее у меня есть хвосты о которых я помню:
1) Дописать итог к серии постов о видах функций
2) Пост с критикой пакетирования по слоям
Плюс я сейчас читаю одну из самых крутых книг по проектированию поста в своей жизни - как дочитаю, обязательно напишу пост-обзор.
Но что, в каком порядке и в какие сроки я опубликую - я уже не берусь предсказывать, так что стей тюнед:)
#posts@ergonomic_code #solid@ergonomic_code
Алексей Жидков
Многоликий принцип единственности ответственности - Алексей Жидков
Принцип единственности ответственности? Что именно вы имеете ввиду?
Привет!
В Applying UML and Patterns вычитал третью интерператцию OCP:
> In the context of OCP, the phrase "closed with respect to X" means that clients are not affected if X changes. For example, "the class is closed with respect to instance field definitions" through the mechanism of data encapsulation with private fields and public accessing methods. At the same time, they are open to modifying the definitions of the private data, because outside clients are not directly coupled to the private data.
Тут под OCP понимается инкапсуляция чего-либо за интерфейсом - т.е. возможность изменить это без изменения клиентов.
Первая интерпретация, у Мейера - язык программирования должен обеспечивать возможность инкапсуляции.
Вторая интерпретация у Мартина - части поведения модуля должны инжектиться, чтобы можно было изменять поведение модуля, без изменения самого модуля.
Кому верить - вопрос на миллион. Наврное всё-таки Мартину, т.к. в этом случае больше вероятность того, что вас правильно поймут.
#books@ergonomic_code #solid@ergonomic_code
В Applying UML and Patterns вычитал третью интерператцию OCP:
> In the context of OCP, the phrase "closed with respect to X" means that clients are not affected if X changes. For example, "the class is closed with respect to instance field definitions" through the mechanism of data encapsulation with private fields and public accessing methods. At the same time, they are open to modifying the definitions of the private data, because outside clients are not directly coupled to the private data.
Тут под OCP понимается инкапсуляция чего-либо за интерфейсом - т.е. возможность изменить это без изменения клиентов.
Первая интерпретация, у Мейера - язык программирования должен обеспечивать возможность инкапсуляции.
Вторая интерпретация у Мартина - части поведения модуля должны инжектиться, чтобы можно было изменять поведение модуля, без изменения самого модуля.
Кому верить - вопрос на миллион. Наврное всё-таки Мартину, т.к. в этом случае больше вероятность того, что вас правильно поймут.
#books@ergonomic_code #solid@ergonomic_code
И к слову, про реальную обратную связь. И про то, что мне не дают покоя лавры анкл Боба:)
Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.
Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)
#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code
Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.
Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)
#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code
❤7