Комментарии 21
На эту тему есть доклад: https://www.youtube.com/watch?v=eVQsWCnSsps
Любопытно, но из этой зависимости наверняка есть море исключений.
Скажем, при работе с внешним железом для драйверов часто пишут один абстрактный класс плюс кучу его конкретных реализаций. Например, абстрактный линейный привод с методами get_position(), go_to_position(), go_home() и разные его имплементации для приводов от разных производителей. Со временем появляются новые производители, меняются поставщики, и конкретных имплементаций становится довольно много.
По вашей шкале такой драйвер неабстрактен (в нем всего один абстрактный класс и куча конкретных) и неустойчив (хороший драйвер обычно много где используется), поэтому должен попадать в "зону боли". Хотя на самом деле работать с ним — одно удовольствие.
Отличная статья! Кратко и ёмко, а главное осталось поле для практических размышлений!
"Чистая архитектура" вообще очень неплохая книга.
Есть спорные штуки, но многие концепции действительно хороши.
А главное, не просто шаблоны и рекомендации, но описание причин, почему они такие.
Например, компоненты с высоким уровнем абстрактности и низкой устойчивостью могут считаться хорошо спроектированными, поскольку они легко адаптируются к изменениям и масштабируются.
Согласно этому положению, хорошо спроектированным является компонент в координатах 
, но, в действительности, это "зона бесполезности".
Кажется, здесь допущена ошибка.
Для примера, сам Мартин пишет
Как компонент с максимальной устойчивостью (I=0) сделать гибким настолько, чтобы он сохранял устойчивость при изменениях? Ответ заключается в соблюдении принципа открытости/закрытости (OCP). Этот принцип говорит, что можно и нужно создавать классы, достаточно гибкие, чтобы их можно было наследовать (расширять) без изменения. Какие классы соответствуют этому принципу? Абстрактные.
, то есть объявляет удачными координаты 
1 конкретный класс с 10 интерфейсами, но используемый напрямую, получается абстрактным.
10 конкретных классов, используемых через 1 единственную абстракцию, получается не абстрактным.
1 класс, зависящий от 10 со стабильными интерфейсами, получается неустойчивым.
10 классов, зависящих от 1 с постоянно меняющимся интерфейсом, получается устойчивым.
А потом по этим цифрам ещё и метрики строят.. на линейных шкалах.. без развесовки.. по которым получается, что для того, чтобы оставаться на главной последовательности, надо:
Вводя 1 новый зависимый компонент, нужно добавить в зависимость 1 новую абстракцию или удалить 1 конкретный класс.
Удаляя 1 зависимый компонент, нужно удалить 1 абстракцию или добавить 1 конкретный класс.
Речь не идет о том чтобы все прижимать к главной последовательности. Если вы написали модуль в зоне боли, но вам никогда не понадобится его изменять, ssl какой нибудь, то и не надо прижимать его к главной последовательности, он нормально будет жить в зоне боли. Если вы хотите более подробно понять мысль, лучше прочитать книгу.
Уж не предлагаете ли вы мне писать плохой, низкокачественный код ssl?
мы сегодня познакомились с метриками, которые могут помочь оценить качество архитектуры кода и выявить области для улучшения.
Нет не предлагал, давайте не будем перевирать слова и придумавать то что не было написано. Эта метрика не панацея, никто не говорит сводите D к нулю для всех модулей. Есть разные факторы и нужно учитывать их все. Если модуль ssl абсолютно устойчив и не абстрактен это нормально, ведь ему и не нужны эти свойства.
То есть эти метрики не могут помочь оценить качество архитектуры кода и выявить области для улучшения? А какие факторы могут?
К сожалению мы никак не сможем найти общий язык. Вы спрашиваете вопросы, на которые выше уже был ответ, делаете выводы которых нет и говорите что это мои слова... Вы либо издеваетесь, либо *****. Поэтому я прощаюсь)
Дураки учатся на своих ошибках. Умные - на чужих. Вот и получается, что умных учат дураки.
Не томите, давайте уже к делу, как $mol поможет писать более качественный код? </sarcasm>
А $mol тут при чём? Про раскладывание файлов у нас есть $mam.
мы можем отказаться от указания версий вовсе. При каждой установке любой зависимости, будет скачан самый актуальный код. Тот код, который сейчас поддерживается мейнтейнером. Тот код, который сейчас видят все остальные потребители библиотеки. И все вместе решают проблемы с этой библиотекой, если они вдруг возникают
Я конечно не всё прочитал, но вот такой подход выглядит ужасно,
И вообще как фраза "мы познакомились с метриками, которые могут помочь оценить качество архитектуры кода и выявить области для улучшения", могла навести на мысль что я предлагаю писать низкокачественный код. У вас странные "логические" суждения.
На эту тему есть доклад: https://www.youtube.com/watch?v=eVQsWCnSsps
Секретный ингредиент для оценки архитектуры кода