Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Каждый раз, когда внутри функции создается объект, появляется зависимость функции от класса этого объекта. Другими словами, функция жестко завязана на работу в паре с конкретным классом. Есть формальный способ, позволяющий легко проверить насколько ваш код завязан в узел. Возьмите любую функцию и мысленно представьте, что вы переносите ее в другой проект. Сколько за собой она потянет зависимостей (а те в свою очередь свои зависимости)? Если перенос функции потребует переноса большого количества кода, то говорят, что в коде высокая связанность.

2 Для развязки кода придуман даже специальный термин:<a>Принцип Инверсии Зависимостей</a>. Еще он известен как<a>DIP</a>из SOLID. Вот его формулировка:

3 <ul><li>Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.</li>

4 <li>Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.</li>

5 </ul>В зависимости от языка, в эти фразы вкладывается немного разный смысл. В общем и целом, они говорят о том, что не нужно завязываться на конкретную реализацию класса. Создание объектов в том месте, где они используются, связывает нас с классом этих объектов без возможности его подменить. Правильный подход, с точки зрения этого принципа, инвертировать зависимости, то есть не работать с классами напрямую, а получать объекты нужных классов снаружи, например, через параметры функции.

6 Кроме того, DIP говорит о завязке на интерфейсы вместо классов в сигнатурах функций. Об этом мы поговорим позже, когда закончим с основными понятиями.

7 Было:

8 Стало:

9 В докладах на тему DIP, докладчики любят в качестве аналогии приводить принцип Голливуда: "Не надо нам звонить, мы сами вас наберем". Под этим имеется в виду, что не нужно пользоваться классами напрямую, а вместо этого получать готовые объекты как внешнюю зависимость.

10 Нужно ли всегда придерживаться этого принципа? Откровенно говоря, код, целиком построенный в таком стиле, становится излишне абстрактным и сложным для понимания. В программировании нет серебряных пуль и в каждой конкретной ситуации нужно смотреть на условия и решаемую задачу. Если подмена реализации нужна, то делаем ее, если нет, то работаем напрямую.

11 Почти всегда, когда речь идет про инверсию зависимостей, рядом появляется термин "инъекция зависимостей". DIP говорит о модульности, а инъекция зависимостей - о том, какими способами можно достичь этой модульности, как передать зависимости в код. Всего есть три способа инъекции зависимостей:

12 <ul><li>Передать их как аргументы функций или методов. Именно этот способ мы использовали до сих пор:

13 </li>

14 <li>Через конструктор в тех ситуациях, где используются объекты:

15 </li>

16 <li>Через сеттеры. По возможности лучше этот способ не использовать, потому что он связан с изменением объектов и нарушением целостности:

17 </li>

18 </ul>Подробнее о последнем способе можно прочитать в<a>курсе по объектно-ориентированному дизайну</a>.

19 Как видите, за громким термином скрывается очень простая штука - передача параметров. С другой стороны, термины позволяют понять больше смысла без необходимости знать дополнительный контекст. Главное не увлекаться, а то можно превратиться в архитектурных астронавтов.