Dependency Injection и Spring4d?

Question

[NSliM]

Читаю книгу Ника Ходжеса Dependency Injection in DELPHI. В главе "Registering Factories" рассматривается такой пример:
Есть интерфейс:

ICoffeeMaker = interface
['{73436E03-EF65-44F5-9606-F706156CBEB5}']
  procedure MakeCoffee;
end;

...и класс его реализующий:

type
  TCoffeeMaker = class(TInterfacedObject, ICoffeeMaker)
    private
      FCoffeeBrand: string;
      FBrewingMinutes: integer;
    public
      constructor Create(const aCoffeeBrand: string; const aBrewingMinutes: integer);
      procedure MakeCoffee;
    end;

constructor TCoffeeMaker.Create(const aCoffeeBrand: string; const aBrewingMinutes: integer);
begin
  inherited Create;
  FCoffeeBrand := aCoffeeBrand;
  FBrewingMinutes := aBrewingMinutes;
end;

procedure TCoffeeMaker.MakeCoffee;
begin
  WriteLn('Pour hot water over the ', FCoffeeBrand, ' so that it brews for ', FBrewingMinutes, ' minutes.');
end;

Далее декларируется функция-фабрика для создания экземпляра ICoffeeMaker:

type
  {$M+}
  TCoffeeMakerFactory = reference to function(const aCoffeeBrand: string; const aBrewingMinutes: integer): ICoffeeMaker;
  {$M-}

...и всё это дело регистрируется в контейнере:

procedure RegisterStuff(aContainer: TContainer);
begin
  aContainer.RegisterType<ICoffeeMaker, TCoffeeMaker>.AsDefault;
  aContainer.RegisterFactory<TCoffeeMakerFactory>;
  aContainer.Build;
end;

И далее приводит код основной программы:

var
  CoffeeName: string;
  BrewingMinutes: integer;
  CoffeeMakerFactory: TCoffeeMakerFactory;
  CoffeeMaker: ICoffeeMaker;
begin
  Write('What kind of coffee do you want to make? ');
  ReadLn(CoffeeName);

  Write('How many minutes? ');
  ReadLn(BrewingMinutes);

  CoffeeMakerFactory := Container.Resolve<TCoffeeMakerFactory>();
  CoffeeMaker := CoffeeMakerFactory(CoffeeName, BrewingMinutes);
  CoffeeMaker.MakeCoffee;
end;

Автор пишет, что регистрировать TCoffeeMaker в контейнере, в принципе, не обязательно. Но вдруг у нас будет какой-нибудь класс TKitchen, у которого в зависимостях будет ICoffeeMaker.
Вопрос в следующем:
Что если действительно есть класс TKitchen, реализующий интерфейс IKitchen, который в конструкторе принимает параметром ICofeeMaker? Получается я его зарегистрирую в контейнере:

begin
  //...
  aContainer.RegisterType<IKitchen, TKitchen>;
  //...
end;

...и далее создам:

begin
  //...
  Kitchen := Container.Resolve<IKitchen>();
  //...
end;

Как в таком случае настраивается передаваемый в его конструктор экземпляр ICoffeeMaker?

Answer 1

[OCTAGRAM]

Смущает конструкция

aContainer.RegisterFactory<TCoffeeMakerFactory>;

Здесь ведь даже не передана никакая реализация функции конструктором.

И от фабрики я бы ожидал, что у неё просто нет параметров, которые движок DI не мог бы подставить. То есть,

TFunc<ICofeeMaker>

А если параметры всё же есть, то либо движок DI должен поискать у себя фабрику строки и целого цисла, либо эти параметры задаются RTTI атрибутами. Или задаются при регистрации какой-то из фабрик, ICoffeeMaker или IKitchen.

Comments

[NSliM]

На самом деле, насколько я понимаю, мы таким образом
aContainer.RegisterFactory<TCoffeeMakerFactory>;
просто сообщаем контейнеру сигнатуру конструктора. А фабрику он формирует сам.

[NSliM]

Собственно моя проблема в том, что все примеры и лекции рассматривают ситуацию разрешения зависимостей на первом уровне. Типа "У нас есть класс А, у которого в зависимостях интерфейс В с вот такой-то реализацией. Регистрируем в контейнере оба класса, и контейнер, при создании экземпляра класса А сам создаст экземпляр класса В". Максимум, что объясняется, так это то, как быть если у В несколько реализаций.
А как быть, если у В есть зависимость от С, а у С несколько реализаций. И у него тоже есть зависимости. Как разрешать зависимости на более глубоких уровнях? В Pure DI это выливается в неиспользуемые классом зависимости, которые он просто пробрасывает своим зависимостям. Но принять он их обязан.