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

Question

Я изо всех сил, чтобы понять, почему инициализация 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(); } 
}; 

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

Answer 1

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

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

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

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

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

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

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

Answer 2

Это похоже, что он использует factory design pattern для создания новых экземпляров t_process. Это позволит вам делегировать ответственность за создание разных типов t_process в классе X

Answer 3

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