Резюме

Механизм внедрения зависимостей по-настоящему расцветает, когда дело доходит до применения объектно-ориентированных принципов, например, SOLID. В частности, слабо связанная природа механизма внедрения зависимостей позволяет нам использовать паттерн Decorator для того, чтобы соблюдать принцип открытости/закрытости, а также принцип единственной ответственности. Эта возможность ценна в широком круге ситуаций, поскольку позволяет нам оставлять наш код чистым и хорошо-структурированным, но применяется особенно хорошо, когда дело доходит до сквозных сущностей.

Сквозные сущности традиционно принадлежат области аспектно-ориентированного программирования, но также могут с большим успехом разрешаться с помощью механизма внедрения зависимостей. Паттерн проектирования Decorator – это основной паттерн, позволяющий нам обертывать существующую функциональность в дополнительные уровни поведения, не изменяя первоначальный код.

Но, несмотря на свои многочисленные достоинства, главная проблема, связанная с реализацией Decorator'ов, – это то, что они склонны к многословности и повторяемости. Даже если вы можете соблюдать SOLID принципы проектирования, мы прекращаем нарушать DRY принцип, поскольку нам нужно писать снова и снова один и тот же код инфраструктуры – для каждого члена каждого интерфейса, который мы хотим расширить с помощью конкретного аспекта.

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

Некоторые DI-контейнеры предлагают более привлекательную альтернативу благодаря возможности динамически порождать Decorator'ы во время выполнения. Эти динамические Decorator'ы обеспечивают перехват, который соблюдает как SOLID, так и DRY принципы.

Интересно отметить, что динамический перехват – единственная особенность DI-контейнеров, которая не имеет прямого эквивалента в Poor Man's DI. С этой точки зрения, в части 3 вы видели, как обращаться с композицией объектов и механизмом управления жизненным циклом с помощью благоразумного применения паттернов, но когда дело доходит до механизма перехвата, самое близкое, что мы получаем – это множество Decorator'ов.

Несмотря на то, что понятие Decorator сравнимо с механизмом перехвата, предпочтителен скачок от множества закодированных вручную Decorator'ов к одному, а также DRY перехватчик. Скачок от множества Decorator'ов к одному может привести к вспышке повторяющегося кода инфраструктуры, тогда как использование DRY перехватчика предлагает возможность обращения к сквозным сущностям с помощью нескольких строк кода и в качестве дополнительного бонуса – возможность использовать применение аспектов на основе соглашений.

Именно здесь, в заключении части 3, мы, наконец, достигаем той области, где DI-контейнеры бесспорно оставляют Poor Man's DI позади. Даже без механизма перехвата DI-контейнер может гораздо лучше управлять сложностью, вложенной в процесс преобразования абстракций к конкретным типам, а также управлять их жизненными циклами; но когда мы добавим к этому сочетанию механизм перехвата, мы уже не сможем разрушить комбинацию.

На этой ноте мы можем с радостью оставить Poor Man's DI за частью 3 и перейти к чтению информации о конкретных DI-контейнерах в части 4.

или RSS канал: Что новенького на smarly.net