Вопрос об инъекции в зависимости

Question

У меня есть вопрос относительно шаблона инъекции зависимостей. Мой вопрос ... Если я иду на инъекцию конструктора, вводя зависимости для моего класса, то, что я получаю, является «большим» конструктором со многими параметрами. Что делать, если есть. Я не использую некоторые параметры в некоторых методах? Т.е. У меня есть служба, которая предоставляет множество методов. И конструктор с 10 параметрами (все зависимости). Но не все методы используют все зависимости. В некотором методе будет использоваться только одна зависимость, другая будет использовать 3 зависимости. Но контейнер DI разрешит их все, даже если они не используются.

Для меня это штраф за выполнение использования контейнера DI. Это правда?

Answer 1

Вы также можете скрыть некоторые не все еще необходимые зависимости от ленивых поставщиков. Например:

public DataSourceProvider implements Provider<DataSource> { 

    public DataSource get() { 
     return lazyGetDataSource(); 
    } 

} 

Provider interface является частью javax.inject пакета.

Answer 2

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

Answer 3

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

Answer 4

Как правило, ограничение производительности при инъекции многих зависимостей низкое, но это зависит от структуры, которую вы выбираете. Некоторые будут компилировать методы для этого «на лету». Тебе придется протестировать это. Многие зависимости показывают, что ваш класс делает слишком много (как сказал Рубен), поэтому вы можете взглянуть на это. Если создание экземпляра функции, которую вы часто не используете, вызывает проблемы с производительностью, вы можете ввести завод в качестве зависимости. Я обнаружил, что использование заводов может решить многие проблемы, связанные с использованием инфраструктур инъекций зависимостей.

// Constructor 
public Consumer(IContextFactory contextFactory) 
{ 
    this.contextFactory = contextFactory; 
} 

public void DoSomething() 
{ 
    var context = this.contextFactory.CreateNew(); 
    try 
    { 
     // use context here 

     context.Commit(); 
    } 
    finally 
    { 
     context.Dispose(); 
    } 
} 

Answer 5

Как rube Говорит, что вы должны рассмотреть дизайн вашего класса, чтобы придерживаться принципов SOLID.

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