Хороший дизайн конструктора

Question

В общем, это плохая идея для построения других объектов внутри конструктора (мне это вообще не нравится)? Предположим, что объекту типа A нужен экземпляр типа B. Экземпляр типа B должен быть статическим, потому что я действительно хочу только одну его копию ... действительно ... нет, серьезно. Тип b также вызывает события, которые должен обрабатывать тип A. Тип B находится во внешней библиотеке, в которой я не контролирую. Создание статического объекта типа B похоже на то, что это будет раздражение при тестировании. Я изначально хотел сделать A полностью статическим, потому что он по существу является прокси B. Возможно, это реальный вопрос. Что такое хороший прокси-дизайн, когда объект, являющийся прокси, требует инициализации? Я думаю, что по крайней мере три варианта:

1. Pass в рассуждениях нужно построить тип А вместе с типом В. Конструктор типа А затем конструирует типа B. (Вызов создать метод для возвращения типа B из внутри конструктора будет таким же основным понятием.
2. Pass в построенном объекте.
3. Создать метод инициализации.

Мне не нравится вариант 1, потому что это просто сложно. Я бы сделать все виды кода инициализации типа B, настроенные накануне nt обработчики и т. д. Мне не нравится вариант 2, потому что я не хочу, чтобы внешний мир знал об этой зависимости. Класс A является единственным типом, который будет взаимодействовать с классом B. В общем, мне не нравятся инициализирующие методы или методы, которые «охраняют» состояние инкапсулированной зависимости. У меня, похоже, много кода:

if (typeB != null && typeB.State != Unitialized) 

Yuck.

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

public class A 
    { 
     private static readonly ILog log = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); 
     private B b; 

     public new A(string productName, string serviceName) 
     { 
      b = new B 
      { 
       ProductName = productName, 
       ServiceName = serviceName 
      }; 

      b.SomethingHappened += b_HandleIt; 

UPDATE: я ссылка this pragmatic article в комментарии к ответу. Я знаком с DI, IoC, Factory Method, Builder Pattern, Injection Designer, Injection, Injection, Test Driven Design и т. Д. Я полагаю, что мой вопрос: как сбалансировать простоту и хороший дизайн при кодировании как можно меньше и как можно быстрее против моих текущих потребностей? Класс B никогда не будет заменен, и у меня нет оснований полагать что-либо, кроме класса A, когда-либо использующего класс B в моем проекте. Меня несколько беспокоит швы для тестирования, но класс А очень прост, имеет мало кода и в основном обертывает сторонний класс.

Answer 1

Закончено с использованием DI с использованием инъекции конструктора. Не был абсолютно взволнован, но это был самый простой подход.

Answer 2

Если вам действительно нужен только один экземпляр типа b, то почему вы имеете дело с ним как часть конструкции на A? Он должен быть членом класса класса B, и вы можете получить его из класса B, когда вам это нужно. Экземпляру класса A не нужен свой собственный указатель на b. (И для него не было бы смысла иметь свой экземпляр b, поскольку есть только один экземпляр.)