Хороший ли дизайн - создание экземпляра вне ComposedObject, который управляет жизненным циклом экземпляра? - PullRequest
Новая
       47

Хороший ли дизайн - создание экземпляра вне ComposedObject, который управляет жизненным циклом экземпляра?

0 голосов
/ 09 мая 2020

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

Я пытаюсь проиллюстрировать свой вопрос с помощью кода C ++ ниже, 

// IObject.h
struct IObject
{
  // other APIs are ignored
  virtual ~IObject() = 0;
};

// Object.h
struct Object : IObject
{
  ~Object() override {}
};

// ComposedObjects.h
struct ComposedObjects
{
  // Constructor used in production
  ComposedObjects();
  // Constructor used in test
  // A IObject mock will be injected
  ComposedObjects(std::unique_ptr<struct IObject> aObject);

  std::unique_ptr<struct IObject> mObject;
};

// ComposedObjects.cpp
ComposedObjects::ComposedObjects()
 : mObject(std::make_unique<Object>())
{

}

ComposedObjects::ComposedObjects(std::unique_ptr<IObject> aObject)
 : mObject(std::move(aObject))
{
}

Вопросы:

  1. Хорошая идея - удалить конструктор ComposedObjects::ComposedObjects() из ComposedObjects класс?

Мое основное намерение удалить конструктор ComposedObjects::ComposedObjects() - следовать принципу единой ответственности, я считаю, что есть две обязанности для вышеуказанного класса ComposedObjects:

  1. создание IObject.
  2. Управление жизненным циклом IObject.

Однако, если создание std::unique_ptr<IObject> перемещается в место, где создается ComposedObjects, я заметил, что вызывающий абонент также должен знать конкретный класс Object вместо I / F IObject.

Насколько я понимаю, абстрактный шаблон фабрики не решает мою проблему, потому что Object должен быть создан до ComposedObjects конструкций.

Большое спасибо за помощь.

...