Принципы

Cohesion

Reuse/Release Equivalent Principle

Классы и модули, которые сгруппированы в компонент, должны и релизиться совместно

Должен быть налажен релизный процесс и компоненты должны версионироваться (например по SemVer)

Как группировать модули в компонентах - это зона ответственности мнйнтейнеров компонентов

Common Closure Principle

В один компонент стоит включать классы, которые меняются по одинаковым причинам и в одно и то же

время. И разделять в разные компонент те классы, что меняются в разное время или по разным причинам.

Больше модулей объединять в 1 компонент для удобства разработки - правки только в 1 компоненте будут чаще

Common Reuse Principle

Не заставляйте пользователей компонента зависеть от вещей, которые им не нужны, поэтому в компоненте должны быть классы и модули, которые переиспользуются

вместе.

Не как объединять, а как разъединять

Диаграмма противоречий

Есть вершины треугольника

Reuse/Release Equivalent Principle

Группировать для переиспользования

Common Closure Principle

Группировать для поддержки и развития

Common Reuse Principle

Разбивать на отдельные компоненты для избегания ненужных релизов

Убрать 1 - Слишком сложно переиспользовать

Убрать 2 - Слишком много изменений (во многих местах)

Убрать 3 - Слишком много ненужных релизов (Пользователям нужно изучать кучу Change log)

Нужно балансировать - выдерживать середину

Coupling

Acyclic Dependencies Principle

Граф зависимостей компонентов должен быть ацикличным

Stable Dependencies Principle

Зависимости должны быть направлены

в сторону устойчивости

/ = FanOut/(FanIn+FanOut) - Нестабильность

1 = 1 - Максимально нестабильный

1 = 0 - Максимально стабильный

Stable Abstraction Principle

Компонент должен быть настолько же

абстрактным, насколько он стабилен.

Nc - Количество классов в компоненте

Na - Количество абстрактных классов

А = Na/Nc - Абстрактность

Зоны:

Зона бесполезности
Зона боли

Нужно быть посередине

Содержание