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?

Comments

[AVSomov]

Стоит понять, что TCoffeeMaker - это "заготовка рецепта", т.к. разные сорта кофе могут готовиться множеством способов.
Т.е. в таком случае: либо TKitchen будет использовать TCoffeeMakerFactory

constructor TKitchen.Create(CoffeeMakerFactory: TCoffeeMakerFactory; ...)

, т.е. кухня будет решать какой кофе и как варить.

Есть другой вариант: все доступные рецепты передаём на кухню.
Например, использовать TCoffeeMaker в паттерне "шаблонны метод", чтобы описать различные рецепты кофе:

TCoffeeFirstBrandFast = class(TCoffeeMaker, ICoffeeMaker)
public
 constructor Create;
end;

TCoffeeSecondBrandSlow = class(TCoffeeMaker, ICoffeeMaker)
public
 constructor Create;
end;

constructor TCoffeeFirstBrandFast.Create;
begin
  inherited Create('FirstBrand', 5);
end;

constructor TCoffeeSecondBrandSlow.Create;
begin
  inherited Create('SecondBrand', 15);
end;

procedure RegisterStuff(aContainer: TContainer);
begin
  aContainer.RegisterType<ICoffeeMaker, TCoffeeFirstBrandFast >('first brand fast');
  aContainer.RegisterType<ICoffeeMaker, TCoffeeSecondBrandSlow>('second brand slow');
  aContainer.RegisterType<IKitchen, TKitchen>();
  aContainer.Build;
end;

constructor TKitchen.Create(CoffeeMakers: TArray<ICoffeeMaker>; ...)

Но в текущем варианте проще обойтись без вспомогательных классов (TCoffeeFirstBrandFast, TCoffeeSecondBrandSlow), а использовать DelegateTo при регистрации:

procedure RegisterStuff(aContainer: TContainer);
begin
  aContainer.RegisterType<ICoffeeMaker>('first brand fast').DelegateTo(
    function: ICoffeeMaker
    begin
      Result := TCoffeeMaker.Create('FirstBrand', 5);
    end
  );
  aContainer.RegisterType<ICoffeeMaker>('second brand slow').DelegateTo(
    function: ICoffeeMaker
    begin
      Result := TCoffeeMaker.Create('SecondBrand', 15);
    end
  );
  aContainer.RegisterType<IKitchen, TKitchen>();
  aContainer.Build;
end;

Answer 1

[OCTAGRAM]

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

aContainer.RegisterFactory<TCoffeeMakerFactory>;

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

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

TFunc<ICofeeMaker>

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

Comments

[NSliM]

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

[NSliM]

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