мне кажется, что вы пришли к распространенному подходу - использовать солид, пока все легко и от него нет проблем, а когда начнутся - смотреть по ситуации. Что опять же возвращает нас к моему изначальному тейку - солид не совсем про гибкость, он про разделение, а гибкость он может как повышать, так и снижать, в зависимости от ситуации
мне так нравятся императивные нотки в вашем комменте))
во-первых, это гипотетический пример, ничего трогать я и не собираюсь)
а во-вторых, раскройте пожалуйста мысль, что тут можно было сделать раньше, если у разных акторов идентичная функциональность? Это в любом случае или переиспользование, а значит общая для разных акторов логика в одном месте, а значит нарушение SRP. Или дублирование.
Это принципиальная проблема "переиспользование XOR изоляция изменений". В контексте солида и SRP про нее обычно не вспоминают, зато она часто всплывает в обсуждении микросервисов, например, где обычно считается, что лучше уж дублирование, чем куча общих зависимостей, из-за которых страдает независимость разработки и деплоя. Либо, если вспомнить метрику "хрупкости" кода и афферентные/эфферентные связи, то всплывет та же самая проблема - переиспользование повышает "хрупкость" кода, так как чем больше входящих связей, тем больше неконтролируемый импакт при изменениях. То есть это не проблема конкретно солида и SRP. Это именно проблема "переиспользование XOR изоляция изменений". Ну или "переиспользование VS снижение сцепленности", можно и так сказать
И делать это без применения головы я бы не советовал категорически.
Это значит, что вы можете вносить изменения в локальный кусок кода, и не беспокоиться о том, что сломается соседний
на мой взгляд как раз "делать с применением головы" чтобы "не беспокоиться о том, что сломается соседний" и означает - понимать вышеуказанные противоречия, понимать, когда у тебя вылезут эти оставшиеся 5 процентов и понимать, что ты с этим будешь делать и почему.
А что для вас в этой формулировке не ясно? Это вполне себе цель. И она не совпадает с просто целью "сделать хорошо".
Как цель - да, вполне норм. Но ведь и Мартин и ваша цитата из вики в треде ниже не про цель, а про свойство SOLID. Типа solid вот это все дает. А это не так.
Т.е. все принципы, по-идее, направлены на то, чтобы изолировать влияние изменений минимально необходимым куском кода, потому что эта изоляция и дает легкость расширения и поддержки. Просто разные принципы - про разные причины изменений и разные способы их "расползания" куда не следует.
Я вот знал, что вы спросите. Представьте себе, что у нас в системе есть два различных актора (к примеру, бугхгалтерия и HR) у которых на текущий момент полностью идентичны требования в некой функциональности. Они могут разойтись в будущем, конечно, но сейчас идентичны. Что тут надо сделать с точки зрения компоновки классов? С точки зрения SRP нужно полностью изолировать функциональность друг от друга, но сейчас она совпадает, так что придется сделать пошлый копипаст. С точки зрения гибкости (и, прости госспади, DRY) общее копировать не нужно, нужно просто его выделить, а различия сделать отдельно. Но тогда два актора будут использовать один общий класс и мы нарушаем SRP. Пример слегка синтетический, но общий конфликт передает. В общем, если коротко, изоляция импакта зачастую мешает переиспользованию. Невозможность переиспользования ломает гибкость.
простите, влезу, но вот вы поцитировали пример типичного маркетинга про solid. Не делает он код более понятным, вообще ни разу. Более того, если вы попробуете пописать код честно так, как описывал Мартин (с этой его ультимативной композицией), вы, возможно, заметите, что ориентироваться по классам стало наоборот сложнее (по крайней мере многие мои коллеги замечали). И с гибкостью есть нюансы, в некоторых случаях может и вредить. Все что реально делает solid - изоляция незапланированного импакта. Все. В качестве побочного эффекта в 95% случаев повышается гибкость (просто за счет разделения всего и вся), но не всегда. А поддерживаемость = гибкость + понятность.
ну, справедливости ради, насколько я помню, Мартин в "чистой архитектуре" тоже явно это не проговаривает, больше отделываясь общими словами типа "гибкость, легкость расширения и поддержки". Хотя с тем же SRP можно привести примеры граничных случаев, когда эти самые "гибкость, легкость расширения и поддержки" он как раз таки ломает в угоду изоляции импакта.
ага, только не лицо, а "актора" - то есть лицо или группу лиц, единообразно использующих систему. И смысл srp ни больше ни меньше просто в снижении незапланированного импакта и потенциального регресса на других акторов. Собственно, как и весь солид, который не про "красивую" или "понятную" архитектуру, а именно про снижение регресса и незапланированного импакта.
Это вообще самая забавная часть всего солида, что мало кто читал Мартина и большая часть воспроизводит пересказы с разной степенью искаженности.
Конечно субъективизм, никто и не спорит. Это топ жалоб именно php-шников, тут вся статья рождена из доклада на внутреннее php-комьюнити на тему "какой боли ждать и к чему вам готовиться морально". Безусловно, у тех, кто переходит из C, ощущения будут совсем другие.
Ну тут же смотря с какой стороны смотреть. Статья (как и изначальный доклад) больше про то, какой боли ожидать при переходе именно php-шникам. А по отзывам, для многих php-шников, которые привыкли к огромным фреймворкам и всяким доктринам, половина кода go-шных сервисов выглядит как велосипеды.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
скажите это товарищам из китая
мне кажется, что вы пришли к распространенному подходу - использовать солид, пока все легко и от него нет проблем, а когда начнутся - смотреть по ситуации. Что опять же возвращает нас к моему изначальному тейку - солид не совсем про гибкость, он про разделение, а гибкость он может как повышать, так и снижать, в зависимости от ситуации
мне так нравятся императивные нотки в вашем комменте))
во-первых, это гипотетический пример, ничего трогать я и не собираюсь)
а во-вторых, раскройте пожалуйста мысль, что тут можно было сделать раньше, если у разных акторов идентичная функциональность? Это в любом случае или переиспользование, а значит общая для разных акторов логика в одном месте, а значит нарушение SRP. Или дублирование.
Это принципиальная проблема "переиспользование XOR изоляция изменений". В контексте солида и SRP про нее обычно не вспоминают, зато она часто всплывает в обсуждении микросервисов, например, где обычно считается, что лучше уж дублирование, чем куча общих зависимостей, из-за которых страдает независимость разработки и деплоя.
Либо, если вспомнить метрику "хрупкости" кода и афферентные/эфферентные связи, то всплывет та же самая проблема - переиспользование повышает "хрупкость" кода, так как чем больше входящих связей, тем больше неконтролируемый импакт при изменениях.
То есть это не проблема конкретно солида и SRP. Это именно проблема "переиспользование XOR изоляция изменений". Ну или "переиспользование VS снижение сцепленности", можно и так сказать
на мой взгляд как раз "делать с применением головы" чтобы "не беспокоиться о том, что сломается соседний" и означает - понимать вышеуказанные противоречия, понимать, когда у тебя вылезут эти оставшиеся 5 процентов и понимать, что ты с этим будешь делать и почему.
Как цель - да, вполне норм. Но ведь и Мартин и ваша цитата из вики в треде ниже не про цель, а про свойство SOLID. Типа solid вот это все дает. А это не так.
Я вот знал, что вы спросите. Представьте себе, что у нас в системе есть два различных актора (к примеру, бугхгалтерия и HR) у которых на текущий момент полностью идентичны требования в некой функциональности. Они могут разойтись в будущем, конечно, но сейчас идентичны. Что тут надо сделать с точки зрения компоновки классов? С точки зрения SRP нужно полностью изолировать функциональность друг от друга, но сейчас она совпадает, так что придется сделать пошлый копипаст. С точки зрения гибкости (и, прости госспади, DRY) общее копировать не нужно, нужно просто его выделить, а различия сделать отдельно. Но тогда два актора будут использовать один общий класс и мы нарушаем SRP. Пример слегка синтетический, но общий конфликт передает.
В общем, если коротко, изоляция импакта зачастую мешает переиспользованию. Невозможность переиспользования ломает гибкость.
простите, влезу, но вот вы поцитировали пример типичного маркетинга про solid. Не делает он код более понятным, вообще ни разу. Более того, если вы попробуете пописать код честно так, как описывал Мартин (с этой его ультимативной композицией), вы, возможно, заметите, что ориентироваться по классам стало наоборот сложнее (по крайней мере многие мои коллеги замечали). И с гибкостью есть нюансы, в некоторых случаях может и вредить.
Все что реально делает solid - изоляция незапланированного импакта. Все. В качестве побочного эффекта в 95% случаев повышается гибкость (просто за счет разделения всего и вся), но не всегда. А поддерживаемость = гибкость + понятность.
ну, справедливости ради, насколько я помню, Мартин в "чистой архитектуре" тоже явно это не проговаривает, больше отделываясь общими словами типа "гибкость, легкость расширения и поддержки". Хотя с тем же SRP можно привести примеры граничных случаев, когда эти самые "гибкость, легкость расширения и поддержки" он как раз таки ломает в угоду изоляции импакта.
ага, только не лицо, а "актора" - то есть лицо или группу лиц, единообразно использующих систему. И смысл srp ни больше ни меньше просто в снижении незапланированного импакта и потенциального регресса на других акторов. Собственно, как и весь солид, который не про "красивую" или "понятную" архитектуру, а именно про снижение регресса и незапланированного импакта.
Это вообще самая забавная часть всего солида, что мало кто читал Мартина и большая часть воспроизводит пересказы с разной степенью искаженности.
да, пример с затенением тут так и напрашивается
но линтеры есть и даже ide такое подсвечивают
Конечно субъективизм, никто и не спорит. Это топ жалоб именно php-шников, тут вся статья рождена из доклада на внутреннее php-комьюнити на тему "какой боли ждать и к чему вам готовиться морально".
Безусловно, у тех, кто переходит из C, ощущения будут совсем другие.
Ну тут же смотря с какой стороны смотреть. Статья (как и изначальный доклад) больше про то, какой боли ожидать при переходе именно php-шникам. А по отзывам, для многих php-шников, которые привыкли к огромным фреймворкам и всяким доктринам, половина кода go-шных сервисов выглядит как велосипеды.