Альтернативы внедрения конструктора (Castle Windsor)

Мне нравится внедрение конструктора для внедрения зависимостей. Это заставляет тип четко объявлять проблемы и помогает с тестируемостью.

Мне нравится внедрение конструктора, в большинстве мест ...

Ведение журнала в качестве примера, где мне это не нравится. Если у меня есть базовый класс, от которого наследуются многие другие классы, и я хочу, чтобы все эти классы использовали экземпляр моего ILogger (или что-то еще), и мне не нужна статическая фабрика (Logger.Instance) ... Я не хочу объявлять конструктор для каждого подкласса, который принимает ILogger.

Итак, я мог бы объявить свой базовый класс регистратор как Свойство и внедрил его таким образом

public class MyBaseClass 
{
   public ILogger Logger { get; set; }
}

... но

  1. Это не уверяет меня, что Logger на самом деле вводится и не имеет значения NULL.
  2. Я не например, иметь ILogger с общедоступным набором

Итак ... какие еще варианты у меня есть? (Я использую Castle Windsor.)

Я подумывал создать интерфейс

public interface IInitializable<T>
{
    void Initialize(T instance); 
}

public class MyBaseClass : IInitializable<ILogger>, ...could have other IInitializables too...
{
   protected ILogger Logger { get; private set; }

   public void Initialize(ILogger instance) 
   { 
         Logger = instance;
   }
}

Затем иметь в моем контейнере средство, которое автоматически вызывает все реализации IInitializable при построении типа .. .

Но мне интересно, что думают другие люди, прежде чем я пойду этим путем ...

6
задан Jeff 9 December 2010 в 17:59
поделиться