Внедрение зависимостей

Внедрение зависимостей часто используется вместе со специализированными платформами, известными как «контейнеры», для облегчения композиции программ.

В разработке программного обеспечения внедрение зависимостей — это метод программирования, при котором объект или функция получает другие объекты или функции, которые ему необходимы, а не создают их внутри себя. Внедрение зависимостей направлено на разделение проблем создания объектов и их использования, что приводит к слабосвязанным программам. Шаблон гарантирует, что объект или функция, желающие использовать данный сервис, не должны знать, как создавать эти сервисы. Вместо этого принимающий « клиент » (объект или функция) получает свои зависимости от внешнего кода («инжектора»), о котором он не знает. Внедрение зависимостей делает неявные зависимости явными и помогает решить следующие проблемы:

• Как класс может быть независимым от создания объектов, от которых он зависит?
• Как приложение и объекты, которые оно использует, могут поддерживать разные конфигурации?

Внедрение зависимостей часто используется для обеспечения соответствия кода принципу инверсии зависимостей .

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

Платформы приложений часто сочетают внедрение зависимостей с инверсией управления . При инверсии управления платформа сначала создает объект (например, контроллер), а затем передает поток управления ему . При внедрении зависимостей платформа также создает экземпляры зависимостей, объявленных объектом приложения (часто в параметрах метода конструктора), и передает зависимости в объект.

Внедрение зависимостей реализует идею «инвертирования контроля над реализациями зависимостей», поэтому некоторые платформы Java в общем называют концепцию «инверсией управления» (не путать с инверсией потока управления ).

Роли

Внедрение зависимости для пятилетних детей

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

Вам следует заявить о своей потребности: «Мне нужно что-нибудь выпить за обедом», и тогда мы позаботимся о том, чтобы у вас было что-нибудь, когда вы сядете, чтобы что-нибудь съесть.

Джон Манш, 28 октября 2009 г.

Внедрение зависимостей включает в себя четыре роли: сервисы, клиенты, интерфейсы и инжекторы.

Услуги и клиенты

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

Любой объект может быть сервисом или клиентом; имена относятся только к той роли, которую объекты играют во время инъекции. Один и тот же объект может быть одновременно клиентом (он использует внедренные сервисы) и сервисом (он внедряется в другие объекты). клиента После внедрения сервис становится частью состояния , доступным для использования.

Интерфейсы

Клиенты не должны знать, как реализованы их зависимости, только их имена и API . служба, которая получает электронную почту Например, IMAP или POP3 , может незаметно использовать протоколы , но эта деталь, вероятно, не имеет отношения к вызывающему коду, который просто хочет получить электронное письмо. Игнорируя детали реализации, клиентам не нужно изменяться вместе с их зависимостями.

Форсунки

Инжектор , иногда также называемый ассемблером, контейнером , провайдером или фабрикой, представляет услуги клиенту.

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

Поскольку внедрение зависимостей отделяет способ создания объектов от способа их использования, это часто снижает важность new Ключевое слово встречается в большинстве объектно-ориентированных языков . Поскольку платформа занимается созданием сервисов, программист склонен напрямую конструировать только объекты значений , которые представляют сущности в предметной области программы (например, Employee объект в бизнес-приложении или Order объект в приложении для покупок).

Аналогия

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

Автомобили имеют единый интерфейс через педали, рулевые колеса и другие элементы управления. Таким образом, какой двигатель им «впрыскивали» на заводе, перестает иметь значение, и водители могут переключаться между любым типом автомобиля по мере необходимости.

Преимущества и недостатки

Преимущества

Основное преимущество внедрения зависимостей — уменьшение связи между классами и их зависимостями.

Если клиент не знает, как реализуются его зависимости, программы становятся более пригодными для повторного использования, тестирования и сопровождения.

Это также приводит к повышению гибкости: клиент может действовать с чем угодно, что поддерживает внутренний интерфейс, который он ожидает.

В более общем плане внедрение зависимостей сокращает количество шаблонного кода , поскольку все создание зависимостей обрабатывается одним компонентом.

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

Тестирование

Многие преимущества внедрения зависимостей особенно актуальны для модульного тестирования .

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

Аналогичным образом, поскольку внедрение зависимостей не требует каких-либо изменений в поведении кода, его можно применять к устаревшему коду в качестве рефакторинга . Это делает клиентов более независимыми, и их легче тестировать изолированно, используя заглушки или макеты объектов , которые имитируют другие объекты, не тестируемые.

Эта простота тестирования часто является первым преимуществом, которое замечают при использовании внедрения зависимостей.

Недостатки

Критики внедрения зависимостей утверждают, что это:

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

Типы внедрения зависимостей

Существует три основных способа получения клиентом инъекционных услуг:

• класса клиента Внедрение конструктора, где зависимости предоставляются через конструктор .
• Внедрение сеттера, когда клиент предоставляет метод сеттера, который принимает зависимость.
• Внедрение интерфейса: интерфейс зависимости предоставляет метод внедрения, который внедрит зависимость в любой переданный ему клиент.

В некоторых средах клиентам вообще не нужно активно принимать внедрение зависимостей. В Java , например, отражение может сделать частные атрибуты общедоступными при тестировании и непосредственном внедрении сервисов.

Без внедрения зависимостей

В следующем Java примере Client класс содержит Service Переменная-член, инициализированная в конструкторе . Клиент напрямую создает и контролирует, какой сервис он использует, создавая жестко запрограммированную зависимость.

public class Client {
    private Service service;

    Client() {
        // The dependency is hard-coded.
        this.service = new ExampleService();
    }
}

Инъекция конструктора

Наиболее распространенной формой внедрения зависимостей является запрос классом своих зависимостей через свой конструктор . Это гарантирует, что клиент всегда находится в допустимом состоянии, поскольку его экземпляр не может быть создан без необходимых зависимостей.

public class Client {
    private Service service;

    // The dependency is injected through a constructor.
    Client(Service service) {
        if (service == null) {
            throw new IllegalArgumentException("service must not be null");
        }
        this.service = service;
    }
}

Инъекция сеттера

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

public class Client {
    private Service service;

    // The dependency is injected through a setter method.
    public void setService(Service service) {
        if (service == null) {
            throw new IllegalArgumentException("service must not be null");
        }
        this.service = service;
    }
}

Внедрение интерфейса

При внедрении интерфейса зависимости совершенно не знают о своих клиентах, но при этом продолжают отправлять и получать ссылки на новых клиентов.

Таким образом, зависимости становятся инжекторами. Ключевым моментом является то, что метод внедрения предоставляется через интерфейс.

Ассемблер по-прежнему необходим для представления клиента и его зависимостей. Ассемблер берет ссылку на клиента, передает ее интерфейсу установки, который устанавливает эту зависимость, и передает ее этому объекту зависимости, который, в свою очередь, передает ссылку на самого себя обратно клиенту.

Чтобы внедрение интерфейса имело значение, зависимость должна что-то делать, помимо простой передачи ссылки на себя. Он может действовать как фабрика или субассемблер для разрешения других зависимостей, тем самым абстрагируя некоторые детали от основного ассемблера. Это может быть подсчет ссылок, чтобы зависимость знала, сколько клиентов ее используют. Если зависимость поддерживает набор клиентов, она может позже внедрить в них всех свой собственный экземпляр.

public interface ServiceSetter {
    void setService(Service service);
}

public class Client implements ServiceSetter {
    private Service service;

    @Override
    public void setService(Service service) {
        if (service == null) {
            throw new IllegalArgumentException("service must not be null");
        }
        this.service = service;
    }
}

public class ServiceInjector {
	private final Set<ServiceSetter> clients = new HashSet<>();

	public void inject(ServiceSetter client) {
		this.clients.add(client);
		client.setService(new ExampleService());
	}

	public void switch() {
		for (Client client : this.clients) {
			client.setService(new AnotherExampleService());
		}
	}
}

public class ExampleService implements Service {}

public class AnotherExampleService implements Service {}

Сборка

Самый простой способ реализации внедрения зависимостей — вручную организовать службы и клиентов, обычно это делается в корне программы, где начинается выполнение.

public class Program {

    public static void main(String[] args) {
        // Build the service.
        Service service = new ExampleService();

        // Inject the service into the client.
        Client client = new Client(service);

        // Use the objects.
        System.out.println(client.greet());
    }	
}

Ручное строительство может быть более сложным и требует участия строителей , фабрик или других строительных структур .

Рамки

Контейнеры, такие как Ninject или StructureMap, обычно используются в объектно-ориентированных языках программирования для реализации внедрения зависимостей и инверсии управления .

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

Некоторые фреймворки, такие как Spring , могут использовать внешние файлы конфигурации для планирования композиции программы:

import org.springframework.beans.factory.BeanFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;


public class Injector {

	public static void main(String[] args) {
		// Details about which concrete service to use are stored in configuration separate from the program itself.
		BeanFactory beanfactory = new ClassPathXmlApplicationContext("Beans.xml");
		Client client = (Client) beanfactory.getBean("client");
		System.out.println(client.greet());
	}
}

Даже при потенциально длинном и сложном графе объектов единственный класс, упомянутый в коде, — это точка входа, в данном случае Client. Client не претерпел никаких изменений для работы со Spring и остается POJO . Благодаря тому, что специфичные для Spring аннотации и вызовы не распределяются по многим классам, система остается лишь слабо зависимой от Spring.

Примеры

AngularJS

В следующем примере показан компонент AngularJS, получающий службу приветствия посредством внедрения зависимостей.

function SomeClass(greeter) {
  this.greeter = greeter;
}

SomeClass.prototype.doSomething = function(name) {
  this.greeter.greet(name);
}

Каждое приложение AngularJS содержит локатор сервисов, отвечающий за создание и поиск зависимостей.

// Provide the wiring information in a module
var myModule = angular.module('myModule', []);

// Teach the injector how to build a greeter service. 
// greeter is dependent on the $window service.
myModule.factory('greeter', function($window) {
  return {
    greet: function(text) {
      $window.alert(text);
    }
  };
});

Затем мы можем создать новый инжектор, который предоставляет компоненты, определенные в myModule модуль, включая службу приветствия.

var injector = angular.injector(['myModule', 'ng']);
var greeter = injector.get('greeter');

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

<div ng-controller="MyController">
  <button ng-click="sayHello()">Hello</button>
</div>

function MyController($scope, greeter) {
  $scope.sayHello = function() {
    greeter.greet('Hello World');
  };
}

The ng-controller Директива запускает инжектор для создания экземпляра контроллера и его зависимостей.

С#

В этом образце представлен пример внедрения конструктора в C# .

using System;

namespace DependencyInjection;

// Our client will only know about this interface, not which specific gamepad it is using.
interface IGamepadFunctionality {
    string GetGamepadName();
    void SetVibrationPower(float power);
}

// The following services provide concrete implementations of the above interface.

class XBoxGamepad : IGamepadFunctionality {
    float vibrationPower = 1.0f;
    
    public string GetGamepadName() => "Xbox controller";
    
    public void SetVibrationPower(float power) => this.vibrationPower = Math.Clamp(power, 0.0f, 1.0f);
}

class PlaystationJoystick : IGamepadFunctionality {
    float vibratingPower = 100.0f;
    
    public string GetGamepadName() => "PlayStation controller";
    
    public void SetVibrationPower(float power) => this.vibratingPower = Math.Clamp(power * 100.0f, 0.0f, 100.0f);
}

class SteamController : IGamepadFunctionality {
    double vibrating = 1.0;
    
    public string GetGamepadName() => "Steam controller";
    
    public void SetVibrationPower(float power) => this.vibrating = Convert.ToDouble(Math.Clamp(power, 0.0f, 1.0f));
}

// This class is the client which receives a service.
class Gamepad {
    IGamepadFunctionality gamepadFunctionality;

    // The service is injected through the constructor and stored in the above field.
    public Gamepad(IGamepadFunctionality gamepadFunctionality) => this.gamepadFunctionality = gamepadFunctionality;

    public void Showcase() {
        // The injected service is used.
        var gamepadName = this.gamepadFunctionality.GetGamepadName();
        var message = $"We're using the {gamepadName} right now, do you want to change the vibrating power?";
        Console.WriteLine(message);
    }
}

class Program {
    static void Main() {
        var steamController = new SteamController();
        
        // We could have also passed in an XboxController, PlaystationJoystick, etc.
        // The gamepad doesn't know what it's using and doesn't need to.
        var gamepad = new Gamepad(steamController);
        
        gamepad.Showcase();
    }
}

Идти

Go не поддерживает классы, и обычно внедрение зависимостей абстрагируется специальной библиотекой, использующей отражение , или дженериками (последнее поддерживается с Go 1.18). ). Более простой пример без использования библиотек внедрения зависимостей иллюстрируется следующим примером веб-приложения MVC .

Сначала передаем необходимые зависимости маршрутизатору, а затем от маршрутизатора контроллерам:

package router

import (
	"database/sql"
	"net/http"

	"example/controllers/users"

	"github.com/go-chi/chi/v5"
	"github.com/go-chi/chi/v5/middleware"

	"github.com/redis/go-redis/v9"
	"github.com/rs/zerolog"
)

type RoutingHandler struct {
	// passing the values by pointer further down the call stack
	// means we won't create a new copy, saving memory
	log    *zerolog.Logger
	db     *sql.DB
	cache  *redis.Client
	router chi.Router
}

// connection, logger and cache initialized usually in the main function
func NewRouter(
	log *zerolog.Logger,
	db *sql.DB,
	cache *redis.Client,
) (r *RoutingHandler) {
	rtr := chi.NewRouter()

	return &RoutingHandler{
		log:    log,
		db:     db,
		cache:  cache,
		router: rtr,
	}
}

func (r *RoutingHandler) SetupUsersRoutes() {
	uc := users.NewController(r.log, r.db, r.cache)

	r.router.Get("/users/:name", func(w http.ResponseWriter, r *http.Request) {
		uc.Get(w, r)
	})
}

Затем вы можете получить доступ к закрытым полям структуры любым методом, который является получателем указателя , без нарушения инкапсуляции.

package users

import (
	"database/sql"
	"net/http"

	"example/models"

	"github.com/go-chi/chi/v5"
	"github.com/redis/go-redis/v9"
	"github.com/rs/zerolog"
)

type Controller struct {
	log     *zerolog.Logger
	storage models.UserStorage
	cache   *redis.Client
}

func NewController(log *zerolog.Logger, db *sql.DB, cache *redis.Client) *Controller {
	return &Controller{
		log:     log,
		storage: models.NewUserStorage(db),
		cache:   cache,
	}
}

func (uc *Controller) Get(w http.ResponseWriter, r *http.Request) {
	// note that we can also wrap logging in a middleware, this is for demonstration purposes
	uc.log.Info().Msg("Getting user")

	userParam := chi.URLParam(r, "name")

	var user *models.User
	// get the user from the cache
	err := uc.cache.Get(r.Context(), userParam).Scan(&user)
	if err != nil {
		uc.log.Error().Err(err).Msg("Error getting user from cache. Retrieving from SQL storage")
	}

	user, err = uc.storage.Get(r.Context(), "johndoe")
	if err != nil {
		uc.log.Error().Err(err).Msg("Error getting user from SQL storage")
		http.Error(w, "Internal server error", http.StatusInternalServerError)
		return
	}
}

Наконец, вы можете использовать соединение с базой данных, инициализированное в вашей основной функции на уровне доступа к данным:

package models

import (
"database/sql"
"time"
)

type (
	UserStorage struct {
		conn *sql.DB
	}

	User struct {
		Name     string `json:"name" db:"name,primarykey"`
		JoinedAt time.Time `json:"joined_at" db:"joined_at"`
		Email    string `json:"email" db:"email"`
	}
)

func NewUserStorage(conn *sql.DB) *UserStorage {
	return &UserStorage{
		conn: conn,
	}
}

func (us *UserStorage) Get(name string) (user *User, err error) {
	// assuming 'name' is a unique key
	query := "SELECT * FROM users WHERE name = $1"

	if err := us.conn.QueryRow(query, name).Scan(&user); err != nil {
		return nil, err
	}

	return user, nil
}

См. также

• Язык описания архитектуры
• Заводской образец
• Инверсия управления
• Плагин (вычисления)
• Паттерн стратегии
• AngularJS
• Шаблон локатора сервисов
• Параметр (компьютерное программирование)
• Кваджект

Внешние ссылки

• «Корень композиции» Марка Зеемана
• Руководство для начинающих по внедрению зависимостей
• Внедрение зависимостей и тестируемые объекты: проектирование слабосвязанных и тестируемых объектов — Джереми Вейскоттен; Журнал доктора Добба , май 2006 г.
• Шаблоны проектирования: внедрение зависимостей - журнал MSDN, сентябрь 2005 г.
• Оригинальная статья Мартина Фаулера, в которой был введен термин «внедрение зависимостей».
• P EAA: Плагин
• Богатое инженерное наследие внедрения зависимостей. Архивировано 13 марта 2008 г. в Wayback Machine - Эндрю Маквей - Подробная история внедрения зависимостей.
• Что такое внедрение зависимостей? - Альтернативное объяснение - Якоб Йенков
• Написание более тестируемого кода с помощью внедрения зависимостей - Developer.com, октябрь 2006 г. Архивировано 11 марта 2008 г. на Wayback Machine.
• Обзор платформы управляемой расширяемости – MSDN
• Старомодное описание механизма зависимости Ханта, 1998 г.
• Рефакторинг вашего пути к контейнеру внедрения зависимостей
• Понимание DI в PHP
• Вам не нужен контейнер для внедрения зависимостей