Какова цель этого кода? - PullRequest
Новая
       16

Какова цель этого кода?

1 голос
/ 23 июля 2010

Я изо всех сил пытаюсь понять, почему инициализация pprocessor, ниже, написана так: 

class X
{
...
private:
   boost::scoped_ptr<f_process> pprocessor_;
};

X:X()
 : pprocessor_( f_process_factory<t_process>().make() ) //why the factory with template
{...}

вместо того, чтобы просто писать 

X:X()
 : pprocessor_( new t_process() ) 
{...}

Другой соответствующий код: 

class f_process {
   ...
};

class t_process : public f_process {
   ...
};


//

class f_process_factory_base {
public:
   f_process_factory_base() { }
   virtual ~f_process_factory_base() = 0 { }
   virtual f_process* make() = 0;
};

template < typename processClass >
class f_process_factory : public f_process_factory_base {
public:
   f_process_factory() { }
   virtual ~f_process_factory() { }
   virtual processClass* make() { return new processClass(); }
};

Парень, который написал код, очень умен, поэтому, возможно, для этого есть веская причина.
(Я не могу связаться с ним, чтобы спросить)

Ответы [ 3 ]

2 голосов
/ 23 июля 2010

Как бы то ни было, это кажется бессмысленным, но я могу представить несколько возможных применений, которые здесь не показаны, но могут быть полезны в будущем:

  • Управление памятью: Возможно, что в какой-то момент в будущем первоначальный автор ожидал, что потребуется другая схема распределения для t_process.Например, он может захотеть повторно использовать старые объекты или выделить новые на арене.

  • Отслеживание создания: Может быть статистика, собранная объектами f_process_factoryкогда они созданы.Возможно, фабрика может сохранять некоторое статическое состояние.

  • Параметры конструктора привязки: Возможно, специализация f_process_factory для t_process в какой-то момент в будущих потребностяхпередать параметры конструктора t_process создателю, но X не хочет знать о них.

  • Подготовка к внедрению зависимости: Это может бытьМожно специализировать эти фабрики, чтобы вернуть издевательства вместо реальных t_process.Это может быть достигнуто несколькими способами, но не совсем так, как написано.

  • Создание специализированных объектов: (Это действительно просто общий случай для предыдущих двух), могут быть специализации t_process, которые создаются в различных обстоятельствах - например, он может создавать разные типы t_process на основе переменных среды или операционной системы.Это потребовало бы специализаций фабрики.

Если бы это был я, и ни один из этих звуков не был бы правдоподобным, я бы, вероятно, разорвал его, поскольку это похоже на беспричинное использование шаблона проектирования.1044 *

2 голосов
/ 23 июля 2010

Похоже, он использует фабричный шаблон для создания новых экземпляров t_process. Это позволит вам делегировать ответственность за создание различных типов t_process от класса X

1 голос
/ 23 июля 2010

Ну, в этом случае это не имеет особого смысла, если только автор не ожидает, что определение фабрики по умолчанию будет обновлено когда-нибудь в будущем.Это имело бы смысл, если бы объект фабрики передавался как параметр;Фабрика дает вам больше гибкости при создании объекта, но если вы создаете экземпляр фабрики в том же месте, где вы его используете, то это действительно не дает преимущества.Итак, вы правы.

...