DI Паттерны. Method Injection

Сегодня мы переходим к самому простому паттерну передачи зависимостей – передаче через аргументы метода, Method Injection.

Существует две разновидности паттерна под названием Method Injection. В некоторых случаях под этим паттерном понимается установка зависимостей объекта с помощью вызова метода:

public interface IDependency
{}
 
public class CustomService
{ 
    private IDependency _dependency; 
    public void SetDependency(IDependency dependency) 
    { 
        _dependency = dependency; 
    }
}

По сути, этот паттерн аналогичен рассмотренному ранее паттерну Property Injection с закрытом геттером, со всеми преимуществами и недостатками. Он применяется в языках без встроенной поддержки свойств, а также может успешно применяться в языке C#, если вам это больше нравится.

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

Описание

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

Назначение

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

Применимость

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

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

1. Метод является статическим и другие варианты не подходят.

public interface ICurrencyRate 
{
     int GetCurrencyRate(string currency);
}
 


// PaymentService 
public static Money CalculatePayment(ICurrencyRate currencyRate) 
{ 
    return new Money(); 
}

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

2. Зависимость может изменяться от операции к операции.

Существует вариант паттерна Стратегия, при котором эта стратегия не может быть передана в аргументах конструктора, поскольку она требуется лишь одному методу и может изменяться от вызова к вызову. Классическим примером такой стратегии может служить стратегия сортировки, передаваемая методу List<T>.Sort().

Этот же подход может применяться и тогда, когда некоторая стратегия доступна в месте вызова операции, а не в месте создания объекта.

// Задает "стратегию" форматирования отчета
public interface IReportFormatter
{ 
    string GetFormatString();
}
  
// ReportService
public string CreateReport(IReportFormatter reportFormatter)
{ 
    return default(string);
}

3. Передача локального контекста для выполнения операции.

Ряд паттернов проектирования, таких как Команда, Состояние и некоторые другие могут использовать дополнительный внешний контекст для выполнения операции. Этот же подход интенсивно используется в многопоточном программировании, когда в поток (или таймер) передается дополнительный контекст, известный вызывающему коду.

public interface ICommandContext
{ 
    int ProcessorCount { get; }
}
 
// CustomCommand
public void Execute(ICommandContext context)
{}

Известные применения

В составе .NET Framework этот подход используется достаточно интенсивно, как в контексте локальных стратегий, так и в контексте передачи контекста исполнения.

Локальные стратегии

IFormatProvider provider = new NumberFormatInfo  { NumberDecimalSeparator = ";" };
// Задаем "стратегию" разбора double
var value = double.Parse("1;1", provider);
 
IComparer<int> comparer = Comparer<int>.Default;
var list = new List<int> {3, 4, 1};
// Передаем "стратегию" сортировки
list.Sort(comparer);
 
var task = Task.Run(() => { });
TaskScheduler taskScheduler = TaskScheduler.Current;
// Задаем "стратегию" запуска "продолжения" задачи
task.ContinueWith(t => { }, 
                    taskScheduler);

Команды в WPF

ICommand command = new RelayCommand();
// В реальности сюда могут приходить данные, необходимые
// для выполенния команды
command.Execute("value");

Дополнительный контекст в многопоточности

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

// Использование контекста для передачи данных в другой поток.
var context = new CustomViewModel();
var thread = new Thread(o =>
{ 
    var localContext = (CustomViewModel) o;
});
thread.Start(context);

Ограничения

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

Кроме того, к этому паттерну нужно отнестись с осторожностью, если он применяется потому, что некоторая зависимость нужна лишь одному методу в классе и нам лень из-за этого протаскивать ее через конструктор. Иногда этот подход оправдан, но он также может означать низкую внутреннюю связность (low cohesion) класса и нарушение Принципа Единой Обязанности: точно ли все нормально, что некоторая зависимость нужна лишь одной операции и не нужна другим методам? Может здесь скрыто два класса?

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

Заключение

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