Low Coupling, High Cohesion

Люблю такие принципы разработки, которые не перевести в лоб, и чтобы понять их надо будет прилично так пораскинуть мозгами и понять чем связность отличается от связности))
По русски лучшим переводом будет: "слабая связность, сильное зацепление", и это один из паттернов GRASP (General Responsibility Assignment Software Patterns) - которые скорее принципы, нежели паттерны и давайте их рассматривать в концепции принципов.

Принцип слабой связности - единица связности (может быть класс, может быть сервис/микросервис в зависимости от масштабов) должна иметь минимальное число зависимостей. На банальном примере: чтобы создать объект класса А, тебе не надо создавать других объектов или импортировать 100500 библиотек. На примере побольше: чтобы развернуть в инфре сервис А, тебе не надо ставить 10 других сервисов и поднимать 5 инфраструктурных узлов. То есть сам по себе твой объект уже красавчик, и ему не нужно много посторонней помощи, чтобы выполнять свои задачи.

Принцип сильного зацепления - для выполнения работы (бизнес-задачи, бизнес-проццесса) все нужные компоненты аллоцированы в одном юните (единице связности, раз уж мы ввели этот термин). Ну и как с low coupling тоже может варьироваться от класса - до сервиса. Чувствуете? Родным SOLID-ом повеяло)) На самом деле очень похоже на принцип Single Responsibility. Явным нарушением будет распределенный-монолит, когда для выполнения 1 метода надо пройти 10 микросервисов, так же нарушением будт просто монолит, потому что зацепление между его функциями слабое. Следованием же high cohesion будет кейс, когда ваш сервис принял пользовательский запрос (например с мобилки) и ему для исполнения запроса не надо ходить ни в какие другие сервисы (собственная БД не считается, она наша, родная). Но при этом внутри вашего сервиса нет левых методов, если он выполняет депозиты - то он не отвечает за in app notifications. Между этой логикой уже нет зацепления.

Такое настроение сегодня, делиться принципами разработки, хорошей пятницы)