#arch #solid #solid4mens #note
Принцип ациклических зависимостей - The Acyclic Dependencies Principle или ADP

Если модули или компоненты системы можно отобразить в виде графа, то в таком графе запрещается иметь циклические зависимости между модулями или компонентами. Принцип ациклических зависимостей гласит, что в таком графе должны быть только однонаправленные зависимости между частями системы.

Представьте, что вы используете базу данных, которая зависит от модуля журналирования для записи времени запуска базы данных. Но модулю журналирования нужна база данных, чтобы узнать, куда записывать время запуска.

Другой пример: вы написали "Модуль Б", который зависит от "Модуля А" и использует функции "Модуля В". "Модуль В" в свою очередь зависит от "Модуля А". Если вы или ваши коллеги внесут изменения в "Модуль Б", то эти изменения затронут "Модуль В", а он затронет код "Модуля А", который затронет код "Модуля Б"... и начнется типичная дилемма курицы и яйца. 🤯

Следование принципу ADP решает эту дилемму и другие проблемы:

1️⃣ Сложность тестирования и обслуживания компонентов системы;

2️⃣ Циклические ссылки на классы создают высокую степень связи; оба класса должны перекомпилироваться каждый раз, когда любой из них изменяется;

3️⃣ Объекты с очень большим количеством циклических ссылок часто являются объектами-богами. Даже если это не так, они имеют тенденцию приводить к спагетти-коду.

* на постере пример системы с циклическими зависимостями.

#arch #note #solid4mens #solid
Принцип эквивалентности повторного использования и выпуска - The Reuse-Release Equivalency Principle или REP

❗️ Принцип гласит, что единица повторного использования не может быть меньше единицы выпуска. Все, что предназначено для повторного использования, должно управляться какой-то системой учета выпусков. Не может быть так, чтобы разработчик просто написал какой-то класс и объявил его повторно используемым. О возможности повторного использования можно говорить только тогда, когда внедрена некая система учета выпусков и обеспечены гарантии извещения, надежности и поддержки, в которых так нуждаются потенциальные пользователи.

❗️ Эффективное повторное использование требует отслеживания релизов в системе контроля изменений

Автору библиотеки необходимо идентифицировать выпуски по каким-либо номерам или названиям. Это позволяет пользователям библиотеки идентифицировать разные версии. Это требует использования какой-то системы отслеживания релизов.

❗️ Единица повторного использования равна единице выпуска.

Можно было бы использовать класс в качестве единицы повторного использования и выпуска, однако в типичном приложении так много классов, что системе отслеживания выпусков было бы обременительно отслеживать их все. Требуется более крупномасштабная организация, и пакет хорошо соответствует этой потребности.

Пакет — это эффективная единица повторного использования и выпуска.

#arch #note #solid4mens #solid
Общий принцип закрытия - The Common Closure Principle или CCP

❗️ Общий принцип закрытия гласит, что классы, которые изменяются по одним и тем же причинам и в одно и то же время, должны быть собраны в компоненты, а классы, которые изменяются в разное время и по разным причинам, должны быть разделены на разные компоненты.

Этот принцип представляет собой переформулировку принципа единой ответственности (SRP), рассмотренного в SOLID , путем применения его к компонентам. Точно так же, как SRP утверждает, что у класса не должно быть более одной причины для изменения, CCP утверждает, что у компонента не должно быть более одной причины причины для изменения.

❗️ Когда необходимо внести изменения в код, идеально, чтобы эти изменения происходили только в одном компоненте, а не в нескольких.

#arch #note #solid4mens #solid
Общий принцип повторного использования - The Common Reuse Principle или CRP

❗️ Принцип совместного повторного использования (CRP) помогает определить, какие классы и модули должны быть включены в компонент. Он говорит, что классы и модули, которые используются вместе, должны быть включены в один компонент.

Также CRP указывает, какие классы не должны быть объединены. Когда один компонент использует другой, между ними возникает зависимость. Даже если использующему компоненту нужен только один класс из используемого, это не уменьшает зависимость. Поэтому, когда происходит изменение в используемом компоненте, обычно требуются соответствующие изменения в использующем компоненте.

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

❗️ Компонент не должен зависеть от того, что ему не требуется.

#arch #solid #note #solid4mens
Диаграмма противоречий для определения связности компонентов

Три принципа связности компонентов вступают в противоречие друг с другом:

1️⃣ Принципы эквивалентности повторного использования (REP) и согласованного изменения (CCP) являются включительными: оба стремятся сделать компоненты как можно крупнее.

2️⃣ Принцип повторного использования (CRP) — исключительный, стремящийся сделать компоненты как можно мельче. Задача хорошего архитектора — разрешить это противоречие.

Диаграмма противоречий, показывающая, как три принципа связности влияют друг на друга. Ребра на диаграмме описывают цену нарушения принципа на противоположной вершине.

❗️ Архитектор, уделяющий внимание только принципам REP и CRP, обнаружит, что простое изменение вовлекает слишком большое количество компонентов. С другой стороны, архитектор, уделяющий особое внимание принципам CCP и REP, вынужден будет выпускать слишком много ненужных версий.

❗️ Хороший архитектор найдет в этом треугольнике противоречий золотую середину, отвечающую текущим нуждам разработчиков, а также подумает об изменениях, которые могут произойти в будущем. Например, на ранних этапах разработки проекта принцип CCP намного важнее, чем REP, удобство разработки важнее удобства повторного использования.

Вообще говоря, в начале разработки наибольшую важность имеет правая сторона треугольника, когда единственной жертвой является повторное использование. Но по мере развития и интеграции в другие проекты фокус начинает смещаться влево. То есть организация компонентов в проекте может изменяться с течением времени. Это больше связано с тем, как проект разрабатывается и используется, нежели с тем, что фактически этот проект делает.