Что такое cohesion и coupling
Теория программирования: пакетные принципы и метрики
Чтобы применять любые принципы правильно, сначала нужно их понять — то есть осознать, откуда они взялись и для чего нужны. Если применять вслепую всё, что угодно — результат будет хуже, чем если бы мы вообще не использовали эти принципы. Я начну издалека и сначала расскажу про абстракцию.
Что есть абстракция?
Это обобщение существенного и удаление несущественного, так как мир настолько сложен, что запрограммировать удаётся только его существенные части. Если попытаемся запрограммировать всё — мы потонем, поэтому абстракция помогает нашему мозгу «впихнуть невпихуемое», как это умеют делают военные (а программисты — пока нет):
Наши проблемы идут от мозга и от того, как устроена наша память. В отличие от хорошего хранилища долговременной памяти, кратковременная устроена по типу stack:
Еще мы используем Chunking (группировку) всякий раз, когда важно запомнить что-то большое. Например, чтобы запомнить число 88003334434, мы разделим его на группы по типу телефонного номера: 8-800-333-44-34. Для нашего мозга получится 5 объектов, которые запомнить легче, чем пытаться удержать число целиком или отдельно каждую его часть.
В коде мы используем слои, чтобы облегчить эту задачу. Однако пять таких слоев в голове удержать становится сложно, а больше пяти — уже проблема. Для лучшего представления это можно сравнить с неправильной супер-лазаньей, в которой слишком много слоёв и — они все слиплись. И это гораздо хуже, чем спагетти — потому что спагетти мы можем отрефакторить и что-то нормальное в результате получить. А чтобы получить что-то нормальное из такой лазаньи, её надо сначала растерзать и превратить в понятные и очевидные спагетти, а потом заново собирать лазанью, только уже правильную.
Поэтому, чтобы совладать с неподъёмно сложными системами, изобретают архитектуру, используя абстракцию. Это не цель, а инструмент, и одновременно — необходимое зло, так как все эти классы, супер-паттерны и прочие шутки не от нашей хорошей жизни.
Но как построить абстракцию, не сделав хуже?
Существует два понятия: cohesion (связность) и coupling (связанность). Они относятся в первую очередь к классам, но в целом и ко всем остальным сущностям. Разницу мало кто видит, так как звучат они почти одинаково.
И, хотя оба означают связь, coupling понимают в негативном ключе. Один объект завязан на другой в плохом смысле, если, ломая один из объектов, ломается всё остальное по цепочке. Cohesion несёт в себе позитивную ноту. Это группировка, в которой то, что близко по смыслу — лежит в одном месте и взаимодействует примерно с теми же местами, опять же близкими по смыслу.
Для того, чтобы понять, coupling у вас или cohesion, существуют проверочные правила. Их сформулировал инженер и специалист в области информатики Роберт Мартин еще в 2000 году, и это — принципы SOLID:
Что есть пакет?
Пакет — это группа единиц кода. Причем, пакеты – это не обязательно пакеты Maven или Composer, или npm. Это программные модули, — то, что вы выделяете в namespaces или иным способом группируете.
Обычно имеются в виду классы, но это могут быть и библиотеки, и модули (не те, которые в фреймфворках, а которые изначально описывали в объектно-ориентированном программировании, то есть группы относящихся друг к другу классов в отдельном namespace). И даже микросервисы можно назвать пакетами — если это настоящие микросервисы, а не те макро-, на которые частенько распиливают монолиты.
И того, кто эти пакеты пилит, обычно волнуют два вопроса: Как правильно формировать пакеты и как работать с зависимостями пакетов?
Как их правильно формировать?
Собственно, cohesion и coupling, как основополагающие принципы, отлично работают и для пакетов. Но сработает ли SOLID для пакетов?
Да, но не совсем. Оказалось, что существуют ещё 6 принципов от того же Роберта Мартина, сформулированные в том же году. Часть из них относится к cohesion, и это о том, как дизайнить код: REP, CCP, CRP. Другая часть — это coupling (то есть использование пакетов): ADP, SDP, SAP — и это о том, как сделать так, чтобы один пакет не завязался на другой и чтобы всё нормально работало:
1 принцип – REP (Reuse-Release Equivalency Principle)
На сегодняшний день этот принцип выглядит до смешного очевидным, но не забываем, что сформулирован он в 2000 году, когда не было таких замечательных штук, как Maven, Composer и прочих, а пакетные релизы были не частыми.
Принцип гласит: «The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package. — что переиспользуем, то и релизим. Эффективно переиспользовать можно только компоненты, релизнутые через системы версионирования. Такие компоненты называются пакетами». То есть упаковывайте то, что переиспользуется в отдельные пакеты и релизьте это через любимый пакетный менеджер, версионируя по SemVer.
2 принцип – CCP (Common Closure Principle)
«Classes that change together are packaged together — изменение в пакете должно затрагивать весь пакет». Этот принцип очень похож на SOLID-ский OCP. Классы, которые изменяются по одной и той же причине, должны упаковываться в один пакет. Что логично.
Нормальный пример: адаптеры. Библиотека, допустим, кеш. Если мы запихиваем в один пакет тучу адаптеров: для файлов, memcached, Redis, то при попытке изменить один какой-то адаптер мы нарушаем два принципа. Во-первых, принцип REP (начинаем релизить один из адаптеров, а релизить приходится все). А во-вторых — принцип CCP. Это когда классы для адаптера под Redis изменяются, а все остальные адаптеры в пакете —нет.
3 принцип – CRP (Common Reuse Principle)
«Classes that are used together are packaged together — Пакеты должны быть сфокусированными. Использоваться должно всё». То есть классы, которые используются вместе — упаковываем вместе. Проверочное правило здесь такое: смотрим, используется ли в нашем софте всё из того пакета, который к нему подключен. Если используется чуть-чуть, значит, скорее всего, пакет спроектирован неверно.
Эти три принципа дают понимание, как пакеты дизайнить. И казалось бы, нормально делай — нормально будет. Однако реальность сурова, и я сейчас объясню — почему. Вспомним треугольник от Артемия Лебедева, который вершины «быстро», «дёшево» и «качественно» обозначил несколько другими словами. Такой же треугольник нарисовали и для пакетных принципов в Институте Макса Планка:
Получается, эти принципы конфликтуют, и в зависимости от того, какие стороны треугольника мы выбираем, вылезают соответствующие косяки:
Теперь переходим к принципам использования.
4 принцип – ADP (Acyclic Dependencies Principle)
«The dependency graph of packages must have no cycles — Если есть циклические зависимости, то проблема вызывает лавину». Если есть циклы, то есть зависимость пакета зависит от самого пакета прямо или косвенно, то косяк в одном пакете вызывает лавину во всех остальных пакетах, и ломается абсолютно всё. К тому же, такие пакеты очень тяжело релизить.
Поэтому надо проверять, есть ли циклы. Для этого необходимо строить направленный граф зависимостей и смотреть на него. Руками это делать не очень удобно, поэтому для PHP есть библиотека clue/graph-composer, которой скармливаешь пакет, и она строит гигантский граф со всеми зависимостями. Смотреть на это, конечно, невозможно, поэтому надо зайти в PR#45, зачекаутить его и выбрать возможность исключать зависимости, которые не интересны. Допустим, если вы пишите фреймворк, то вам скорее всего интересны зависимости на свои пакеты, а чужие — не так сильно, ведь свои косяки поправить можем, чужие — тяжелее. И получается вот такой граф:
Если мы видим — как здесь — что циклических зависимостей нет, то всё отлично. Если есть, надо исправлять. Чем меньше зависимостей, тем проще.
Как разорвать цикл?
5 принцип – SDP (Stable Dependencies Principle)
Это принцип стабильных зависимостей: «Depend in the direction of stability — Не получится строить стабильное на нестабильном». Нестабильность считается так:
Если на нас завязалось очень много всего — скорее всего, мы стабильны. Если же мы завязались на много всего, то, очевидно, мы не очень стабильны. Как повысить стабильность? Следующим принципом.
6 принцип – SAP (Stable Abstraction Principle)
Принцип стабильных абстракций гласит «A package abstractness should increase with stability — Стабильные пакеты абстрактны / Гибкие конкретны». То есть абстрактность должна возрастать со стабильностью. Стабильность здесь — то, как часто нам приходится менять части пакета: классы, интерфейсы, или что-либо ещё. Абстрактные пакеты должны быть стабильны, чтобы безболезненно на них завязываться. В примере с тем же кэшем пакет с интерфейсом будем сверхстабильным, потому что менять интерфейс, про который мы договорились и хорошо над ним подумали — скорее всего, не придётся. Если мы, конечно, абстрагируем не СУБД.
А вот гибкие пакеты, наоборот, конкретны — они должны быть нестабильны, чтобы мы их легко меняли. Все наши приложения, наши конечные пакеты — это на самом деле дико нестабильная штуковина, которая зависит от тучи всего и ломается чаще, чем пакеты, от которых она зависит.
Можно ли измерить абстрактность?
Конечно. Абстрактность — это число абстрактных классов и интерфейсов в пакете, деленное на общее число классов и интерфейсов в этом самом пакете:
Еще есть такой полезный показатель, как D-метрика, в которой по вертикали — нестабильность, а по горизонтали — абстрактность. По двум зонам — вверху справа и внизу слева — мы можем понять:
Линия посередине называется главной линией, и если классы и интерфейсы попадают на неё или выстраиваются вдоль — это тот случай, когда всё отлично. По сути, D-метрика — это дистанция от главной линии, поэтому 0 в этом случае — это хорошо, а 1 — плохо. Но, как правило, ни то, ни другое не случается — значения плавают в диапазоне от 0 до 0,9-0,7. Считается метрика так:
Для PHP есть 2 инструмента для того, чтобы посмотреть метрику своих пакетов:
Как и SOLID, все эти дополнительные принципы и метрики — не догма, но могут быть весьма полезными.
Резюме
Конечно, есть области, в которых можно сознательно игнорировать все эти принципы, отдавая себе отчёт в том, что за этим стоит и где вы можете получить проблемы.
Данные принципы же позволяют не скатываться в монолит или в left-pad из npm. С left-pad была в свое время история — его создали для добавления символа в конце строки, так как в JavaScript есть традиция дробить пакеты вообще в пыль. А потом на этот пакет завязалось практически всё — вплоть до пакетных менеджеров и самых крутых фреймворков. В какой-то момент автор обиделся на всех и выпилил left-pad из системы — после чего, как вы понимаете, сломалось всё. Рассмотренные принципы, в том числе, позволяют уменьшить вероятность такого сценария.
Единственная конференция по PHP в России PHP Russia 2021 пройдет в Москве 28 июня. Первые доклады уже приняты в программу!
Купить билеты можно тут.
Хотите получить материалы с предыдущей конференции? Подписывайтесь на нашу рассылку.
Low Coupling и High Cohesion
Качественный дизайн обладает слабой связанностью (low coupling) и сильной связностью (high cohesion).
Это значит, что программный компонент имеет небольшое число внешних связей и отвечает за решение близких по смыслу задач.
Связанность (Coupling)
Связанность, сопряжение (coupling)— способ и степень взаимозависимости между программными модулями; сила взаимосвязей между модулями; мера того, насколько взаимозависимы разные подпрограммы или модули.
Сильная связанность (High coupling) рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности.
Слабая связанность (Low coupling), напротив, является признаком хорошо структурированной и хорошо спроектированной системы, и, когда она комбинируется с сильной связностью(high cohesion), соответствует общим показателям хорошей читаемости и сопровождаемости.
Low Coupling — это принцип, который позволяет распределить обязанности между объектами таким образом, чтобы степень связанности между системами оставалась низкой.
Степень связанности (coupling) — это мера, определяющая, насколько жестко один элемент связан с другими элементами, либо каким количеством данных о других элементах он обладает.
Элемент с низкой степенью связанности (или слабым связыванием) зависит от не очень большого числа других элементов и имеет следующие свойства:
Виды связанности
Связанность содержимого (content coupling)
Связанность через общее (common coupling)
Связанность через внешнее (external coupling)
Связанность по управлению (control coupling)
Связанность по структурированным данным (data-structured coupling, stamp couplig)
Связанность через данных (data coupling)
Связанность по сообщениям (message coupling)
Отсутствие связанности (no coupling)
Закон Деметры
Принцип наименьшего знания
Закон Деметры (Law of Demeter, LoD) — набор правил проектирования при разработке программного обеспечения, в частности объектно-ориентированных программ, накладывающий ограничения на взаимодействия объектов (модулей).
Обобщенно, закон Деметры является специальным случаем слабой связанности (loose coupling). Правила были предложены в конце 1987 в северо-восточном Университете (Бостон, Массачусетс, США).
Говоря упрощённо, каждый программный модуль:
Общее описание правила: Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C.
Таким образом, код a.b.Method() нарушает Закон Деметры, а код a.Method() является корректным.
Преимущества
Преимуществами закона Деметры является то, что код, разработанный с соблюдением данного закона, делает написание тестов более простым, а разработанное программное обеспечение менее сложно при поддержке и имеет большие возможности повторного использования кода. Так как объекты являются менее зависимыми от внутренней структуры других объектов, контейнеры объектов могут быть изменены без модификации вызывающих объектов (клиентов).
Недостатки
Недостатком закона Деметры является то, что иногда требуется создание большого количества малых методов-адаптеров (делегатов) для передачи вызовов метода к внутренним компонентам.
Связность (Cohesion)
Связность, или прочность (cohesion) — мера силы взаимосвязанности элементов внутри модуля; способ и степень, в которой задачи, выполняемые некоторым программным модулем, связаны друг с другом.
Cвязность характеризует то, насколько хорошо все методы класса или все фрагменты метода соответствуют главной цели, — иначе говоря, насколько сфокусирован класс. Стив Макконнелл
Считается, что объект (подсистема) обладает высокой связностью (High cohesion), если его обязанности хорошо согласованы между собой и он не выполняет огромных объемов работы.
Класс с низкой связностью(low cohesion) выполняет много разнородных функций или несвязанных между собой обязанностей. Такие классы создавать нежелательно, поскольку они приводят к возникновению следующих проблем:
Классы с низкой степенью связности, как правило, являются слишком «абстрактными» или выполняют обязанности, которые можно легко распределить между другими объектами.
Виды связности
Случайная (coincidental cohesion)
Логическая (logical cohesion)
Временная (temporal cohesion)
Процедурная (procedural cohesion)
По взаимодействию (communication cohesion)
По последовательности действий (sequential cohesion)
Функциональная (functional cohesion)
Качество кода: слабое связывание и высокая сопряженность (Low coupling and High Cohesion)
Вступление:
И так здравствуйте меня зовут Крючков Владимир Вячеславович. Сегодня я хочу поднять актуальный и фундаментальный вопрос в процессе разработки – Слабое связывание и Высокое сопряжение/зацепление. Узнаем что из себя представляет спагетти-код и как от него избавиться. И в конце приведу 7-8 принципов для создания хорошего и качественного кода в разработке.
Подготовьтесь! Выпейте кофе, чай с сахаром или шоколадом, чтобы взбодриться и приготовьтесь поглощать информацию.
Я снабдил каждый важный слайд картинкой, подходящий под описание и хочу, чтобы у вас закрепилась данная ассоциация) А еще лучше если вы станете применять некоторые принципы в своей повседневной работе.
О чем речь?
Речь пойдет о фундаментальных принципах проектирования и разработки программного обеспечения. Многие вещи программисты делают по наитию, через опыт, а мы сегодня попробуем структурировать и приложить к методологии эти знании.
На самом деле это принцип взят и теории ООП. Эти два принципа входят в аббревиатуру GRASP. В 1С нет как таковы классов, но описанные принципы можно применить и к языку 1С Enterprise.
Шаблоны GRASP.
Это два шаблона из GRASP (англ. general responsibility assignment software patterns — общие шаблоны распределения ответственностей).
Их всего девять. Некоторые выделяют 5 основных и 4 дополнительных.
Мы сегодня поговорим про два из них – слабое связывание и высокое сопряжение.
Что за сущность класс в 1С?
Прежде чем продолжим давайте попробуем провести некоторую аналогию с классом и будем называть ее сущность. К сущности я отношу набор понятий и каждый раз может меняться в зависимости от ситуации.
Слабое связывание.
Картинка у вас надеюсь вызывает ассоциацию перехода от клубка запутанных и ветвистых нитей к их упорядочиваю и переходу. Попробуйте себя ассоциировать с тем человечком «программистом», достигшим просветления 🙂
Проблема
И так у нас есть проблема, задача. Она может быть сформулирована следующим образом:
Как обеспечить независимость, незначительное влияние изменений и повысить возможность повторного использования?
Мы хотим получить код/архитектуру решений более независимую от влияния изменений и повысить возможность повторного использования.
Что значит независимую от влияния изменений – это значит если мы хотим поправить в некоторой маленькой функции маленький кусочек кода, то это должно быть без довеска необходимости менять все файлы конфигурации.
Пример: все знают БСП? Вот я вспоминаю один случай, когда они изменили местоположение функции «Текущий пользователь» из общего модуля «Общего Назначения» в «Пользователи», то пришлось перелопатить всю конфигурацию, когда мы накатывали обновление БСП, т.е. они нарушили принцип «открытый/закрытый» об этом речь пойдет ниже.
Что значит повторное использование кода – это значит, что я пишу функцию или процедуру не для одного случая и называю ее «Получить Реквизит Сумма Заказа Клиента», а «Получить Реквизиты Объекта». В результате я смогу вызывать ее многократно и не писать каждый раз новый код, замусоривая конфигурацию (вспоминаем про рефакторинг).
Решение.
Требуется распределять обязанности, чтобы степень связанности осталась низкой.
I) Слабая связанность.
Что такое слабая связанность?
Это мера на сколько жестко связан один элемент с другими, либо каким количеством данных/информации обладает о других элементах.
Ниже приведу примеры по типу плохо и хорошо.
Найди нужную нить!
Если элементы сильно связаны, то любое их изменение приводит к изменению во всех связанных объектах. Слабо проследить нить решения?
Особенно в некоторых ситуациях. И я думаю вы встречались с ситуацией, а фиг его знает, что там происходит, давайте напишем в стороне? И тем самым мы добавляем еще одну нитку в этот клубок.
Если все распутать
Чем меньше элемент знает о соседях, тем лучше.
Проблемы высокой связанности.
Идем дальше и поговорим о высокой связанности. И к основным проблемам высокой связанности можно отнести следующие утверждения:
Сильное связывание. Пример.
Посмотрите на пример и увидите одну из самых плохих ситуаций, которые вызывает следование принципу создание высоких связей в коде. Оба модуля переплетены максимально и взывают функции и процедуры из друг друга. А теперь представьте, что этих модулей 1000 как в ERP!
Лучше слабое связывание. Пример.
Смотрим на картинку ниже и видим, что перекрестные ссылки исчезли. Появилась прозрачность и исчезла запутанность для понимания кода и последовательности операций.
Хочу отметить, что четкого требования делать все слабо связанно нет, но стремиться к такой ситуации необходимо всегда.
Сущности, которые являются достаточно общими по своей природе и с высокой степенью вероятности будут повторно использоваться в дальнейшем, должны иметь минимальную степень связанности с другими сущностями.
II) Высокая сопряженность.
И так вторая сущность — это высокая сопряженность или зацепление – перевод с английского. Текущая заставка должна направить ваше мышление на то, о чем пойдет далее речь.
Проблема
Рассмотрим проблему/задачу, сформулированную следующим образом:
Как обеспечить возможность управления сложностью?
Хотим обеспечить возможность управления сложностью? Звучит фантастически, но хорошо)
Что понимаем под сложностью? Это то на сколько тяжело выглядит ваш код и вообще вся структура – сколько из него торчит костылей и потрачено скотча, сколько мегабайт весит все это чудо, сколько функций и объектов в нем утонуло.
Решение.
Распределять обязанности, поддерживающие высокую сопряженность/зацепление (сгруппированность).
Сильное сопряжение. Определение.
Сопряженность/зацепление (в основном функциональное зацепление) – это мера связанности и сфокусированности обязанностей.
Т.е. у нас есть группировка по функциональному (самый оптимальный), логической, структурной и др. принципу.
Пример Бардак.
Представьте себе магазин, в который вы пришли за покупками (пончики, лимоны и кофе). А у них пронесся ураган, и вместо сгруппированных по полочкам и отделам/рядам стеллажам валяется как попало и вперемешку. И вот в этом бардаке вам надо найти лимон, кофе и пончики. А магазин размером с АШАН?
Ваш код тоже похож на вот это?
Порядок.
Но лучше все же так. Вон видите указатель на кофе, а вон бакалея и пончики!
Слабое сопряжение проблемы.
Слабое сопряжение привносит нам следующий перечень проблем:
Пример код слабая сопряженность.
Смотрим и видим, что не понятно какую функциональную обязанность выполняет данный модуль, всего понемножку. На мой взгляд этот общий модуль должен называться как «Общий модуль. Помойка», согласны?
Выдохнули. Немного котиков, чашку чая, отвлекитесь.
Сейчас было тяжело. Не так конечно, как мне вчера в 23 часа вечера, но тоже не просто) Вопросы? Передохнули? Продолжаем?
Как вы думаете к чему приведет использование антирекомендаций – сильное связывание и слабое сопряжение? Смотрите ниже, чтобы знать ответ.
III) Спагетти код и распутывание
Спагетти код и макаронная архитектура.
Рецепт
И так вот вам рецепт хороших макарон, но плохого кода.
Распутываем. Иерархическая декомпозиция.
Сначала код разделяется на несколько больших частей – к примеру, подсистем. Далее эти подсистемы дробятся на более мелкие сущности. В процессе дробления происходит перегруппировка связей, иногда можно ввести некоторого посредника на которого замкнуть все эти связи.
Известный факт, что одни из самых лучших систем – это системы, обладающие модульностью. Это свойство системы, разбитой на множество модулей с высокой сопряженностью и низкой связанностью.
Распутываем. Дао хорошей разработки.
И так переходим к заключительной части. Это некоторые правила хорошего тона, которые вы должны помнить и всегда вспомнить при разработке кода. Я специально нашел картинки и придумал/нашел ассоциации чтобы они вам запомнились.
1) Будь скромным
Не вставляйте на показ процедуры, функции, переменные, объекты и данные.
К примеру, мы сделали экспортную в модуле формы или глобальную переменную. Теперь ее начали использовать в коде и что получаем? Если мы захотим ее переименовать, то придется менять ее вызовы и использование во всех точках кода!
Правильно сделать экспортную функцию, которую вызвать. В ООП – это запрет использовать public везде, у нас это экспорт и непосредственное обращение к регистрам и т.д.
Будь скромным. Пример плохой
Вот так делать нельзя. Пример с усилением акцента, но так тоже пишут.
Будь скромным. Пример правильно
Вот так делать правильнее! Используем шаблон наблюдатель.
2) Принцип минимальности.
Идеальная функция, процедура обладает следующими свойствами:
Принцип модульности, чем из более простых кирпичиков кода будет сложен модуль, тем более понятным и прочным будет здание.
3) Закон Деметры.
Если «А» знает «Б», а «Б» знает «С», то «А» не должна знать про «С».
Это один из принципов противодействия запутыванию кода.
Закон Деметры. Пример
Если модуль «Заказ клиента» вызывает модуль «Продажи», а «Продажи» вызывает модуль «Лимиты», то «Заказ клиента» не должен вызывать функции модуля «Лимиты».
4) Не смотри на медузу Горгону
Смотри на объекты через «зеркало» интерфейсов. 
Суть в том, что если ваш код не опирается на подготовленные блоки, а изобилует велосипедами, то он можно сказать «окаменевает», становится тяжелым на изменения.
Не смотри на медузу Горгону. Пример плохой код
Плохо непосредственно обращаться к данным. Т.е. этим образом вы сразу нарушаете принцип слабого связывания.
Не смотри на медузу Горгону. Пример хороший код
Правильно работать через интерфейсы.
5) Разделяй и властвуй.
Не стоит писать мега функции, разделяем на части и получаем профит.
6) Гусь свинье не товарищ.
Процедуры и функции должны группироваться или объединяться по некоторой общности.
Тут думаю понятно свалка и бардак всегда плохо. Высокое сопряжение нам тут поможет.
7) Принцип открытости и закрытости.
Будьте открыты для всего нового в будущем, но не переписывайте прошлое.
Это мой любимый принцип. Суть в том, чтобы при модификации приложений мы не переписывали старые функции, а только добавляли новые. Иными словами, мы должны всегда писать новый код.
8) Мысли паттернами.
Подходите к решению задачи используя готовые алгоритмы и принципы проектирования. Выбирайте подходящий по критериям и начинайте разработку, а не придумывайте что-то свое.
Это также один из основных принципов, мы должны начинать при написании кода автоматически вспоминать, перебирать и подставлять подходящий паттерн под задачу. О них более подробно расскажу позже. Мы покажем действие паттернов на примерах, и убедимся, то что некоторые из них используем неосознанно.
Заключение. Инь и Янь.
Связывание и зацепление — это «Инь» и «Янь» проектирования ПО.
И так как вы поняли, то эти два подхода идут вместе, и они как Инь и Янь. Только с опытом приходит понятие тонкой грани баланса. Для достижения качественного и сбалансированного кода применяйте к разработке принципы, которые мы рассмотрели выше и прибудет с нами сила!
Про качество кода я рассказывал в этих статьях: