Рубрика «dependency injection» - 9

«Не звони нам. Мы позвоним тебе сами.» — принцип Голливуда

Внедрение зависимости (Dependency Injection — DI) означает передачу (внедрение) одной или более зависимости какому-либо объекту (клиенту, компоненту) таким образом, что после внедрения эта зависимость становится частью состояния объекта. Это немного напоминает паттерн проектирования Стратегия, с той лишь разницей, что стратегия задаётся лишь однажды — в конструкторе. DI позволяет создавать более слабо-связанную архитектуру приложения, которая лучше поддаётся поддержке и тестированию.

Итак, ещё раз плюсы:

  • Уменьшает связность компонент (отделяет бизнес-логику от создания объекта)
  • Позволяет писать более поддерживаемый код (в одни и те же объекты мы легко можем внедрять разные зависимости)
  • Позволяет писать более тестируемый код (мы можем легче использовать стабы и моки)
Без внедрения зависимости С внедрением зависимости
class example {                         
public:  
    example()                           
        : logic_(new logic{})           
        , logger_(                      
            logger_factory::create()    
          )                             
    { }  
         
    int run() const;                    
         
private: 
    shared_ptr<ilogic> logic_;          
    shared_ptr<ilogger> logger_;        
};                             

 class example {
 public:
     example(shared_ptr<ilogic> logic
           , shared_ptr<ilogger> logger)
       : logic_(logic), logger_(logger)
     { }

     int run() const;

 private:
     shared_ptr<ilogic> logic_;
     shared_ptr<ilogger> logger_;
 };

Читать полностью »

Да-да, вы все правильно поняли, это статья об еще одном велосипеде — о моем Dependency Injection (DI) контейнере. За окном уже 2015-ый год, и самых разных контейнеров на любой вкус и цвет полным полно. Зачем может понадобиться еще один?

Во-первых, он может просто образоваться сам собой! Мы в Эльбе довольно долго использовали этот контейнер, и некоторые из описываемых в статье идей (Factory Injection, Generics Inferring, Configurators) изначально были реализованы поверх него через публичное API.

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

В-третьих, DI-контейнер — относительно простая штука. Он очень хорошо поддается разработке в режиме TDD, за счет чего делать его становится весело и приятно.

Эта статья — не введение в DI. На эту тему есть много других прекрасных публикаций, в том числе и на Хабре. Скорее здесь собран набор рецептов приготовления DI так, чтобы получившееся блюдо было вкусным, но не острым. Если у вас DI-контейнер в продакшене или вы написали свой собственный самый лучший контейнер, то здесь отличное место для холиваров о том, чей контейнер круче!
Читать полностью »

Привет!

При ознакомлении с разработкой под Unity3D, для меня, пришедшего из мира Java и PHP, довольно необычным стал подход к внедрению зависимостей на данной платформе. В основном, конечно, это связано с недоступностью конструкторов MonoBehaviour и ScriptableObject, создание объектов вне доступа разработчика, а также наличие редактора, в котором можно конфигурировать каждый объект индивидуально или целыми префабами (при этом оставляя возможность один из экземпляров префаба изменить на своё усмотрение в процессе создания сцены).
Читать полностью »

TL;DR: пакет для легкой регистрации (и конфигурации) AutoMapper в Unity.

var container = new UnityContainer();
container.RegisterMappingProfile<DataModelToViewModel>();
container.RegisterMapper();

public SomeController(IMappingEngine mapper)
{
	_mapper = mapper;
}

public ViewModel SomeAction()
{
	return _mapper.Map<ViewModel>(dataModel)
}

Читать полностью »

О боже, ещё один пост о Inversion of Control

Каждый более-менее опытный программист встречал в своей практике словосочетание Инверсия управления (Inversion of Control). Но зачастую не все до конца понимают, что оно значит, не говоря уже о том, как правильно это реализовать. Надеюсь, пост будет полезен тем, кто начинает знакомится с инверсией управления и несколько запутался.

Читать полностью »

Уже в этот четверг, 23 октября, сообщество SPB Frontend совместно с «Зоной действия» проведут очередную встречу.

image

Ожидается доклад + QA-сессия от разработчиков из питерского Google и аж два доклада про dependency injection в современных фреймворках и вне их.

Читать полностью »

Понятия «инверсия управления» и «внедрение зависимостей» не являются новыми, но в сообществе JavaScript, несмотря на его бурный и продолжительный рост, почему-то встречаются довольно редко.

Независимо от контекста исполнения, расширяемое и поддерживаемое javascript-приложение, как и приложение, написанное на любом другом языке, должно соответствовать некоторым архитектурным принципам. Одним из которых является инверсия управления. Читать полностью »

Спасибо! И позвольте, я объяснюсь.

В первую очередь, спасибо всем, кто прочитал предыдущие части. Много интересных комментариев написали, и я понял, что должен объяснить, зачем я, собственно, всё это пишу? Зачем мне вообще нужно отделять контроллеры от фреймворка? Скорее всего, об этом не придется думать, потому что

Шансы, что контроллеры придется переносить на другой фреймворк, близки к нулю. (Рафаэль Домс)

Читать полностью »

В предыдущей части этой серии мы понизили связанность симфонийского контроллера и фреймворка, удалив зависимость от базового класса контроллера из FrameworkBundle. А в этой части мы избавимся от некоторых неявных зависимостей, которые появляются из-за аннотаций.
Читать полностью »

Обычно считается, что контроллеры — наиболее связанные классы в приложении. Как правило, на основании данных запроса они получают или сохраняют данные в базу данных, затем превращают данные или результат сохранения в HTML, который выступает в качестве ответа клиенту, который произвел запрос.

Получается, что контроллеры — повсюду, они соединяют те части приложения, которые обычно достаточно независимы друг от друга. Это сильно повышает связанность контроллеров: среди их зависимостей есть менеджер сущностей Doctrine, шаблонизатор Twig, базовый контроллер из FrameworkBundle, и прочее.

В этой записи я покажу, что этот уровень связанности совершенно не нужен. Я покажу вам, как значительно понизить связанность, предприняв всего несколько простых шагов. В результате мы получим контроллер, который можно будет повторно использовать в разных типах приложений, например, на базе Silex или даже Drupal.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js