Здравствуйте, Тёмчик, Вы писали:

Тё>Просто ты не умеешь их готовить

Я хорошо умею готовить без них, так что, лишний мусор в коде мне нафиг не нужен.

Здравствуйте, Тёмчик, Вы писали:

Тё>Т.е. ты против всего хорошего, aka loose coupling

О! А можно на примере показать, как DI помогает loose coupling? Пусть вот у нас есть уже упомянутый SpellChecker. Точнее нет, у нас их три:

class RealSpellChecker implements SpellChecker {
}

class CachingSpellChecker implements SpellChecker {
  public CachinSpellChecker(SpellChecker peer, long cacheSize) {
  }
}

class MetricsSpellChecker implements SpellChecker {
  public MetricsSpellChecker(SpellChecker peer) {
  }

  int getCallCount() { return 1; }
  int getGrammarErrorCount() { return 42; }
}

Где и как предлагается описывать, какой их них в кого вкладывается? В самих классах в виде аннотации Named? Там это loose coupling нарушается самым криминальным образом. Классы вместо независимых становятся привязаны к их месту в структуре приложения. В фабриках? Так ручная инициализация в main будет понятнее. В реальной жизни я еще могу иметь несколько экземпляров SpellChecker (разные языки) и вокруг них разные обертки.

Ну и вопрос со звездочкой. Изобразить на DI цепочку MetricsSpellChecker->CachinSpellChecker->MetricsSpellChecker->RealSpellChecker. Две обертки в MetricSpellChecker, на разных уровнях. Может я хочу эффективность кэша посчитать по-простому .