我正在努力理解为什么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(); }
};
编写代码的人非常聪明,所以也许有充分的理由 (我无法联系他询问)
答案 0 :(得分:2)
看起来他正在使用factory design pattern来创建t_process的新实例。这将允许您将创建不同类型的t_process的责任委托给X类
答案 1 :(得分:2)
实际上,它看起来有点毫无意义,但我可以想到一些未在此处展示的可能用途,但在将来可能会有用:
内存管理:在未来的某个时刻,原作者可能会预期t_process
需要不同的分配方案。例如,他可能想要重用旧对象或从竞技场中分配新对象。
跟踪创建: f_process_factory
个对象在创建时可能会收集统计信息。也许工厂可以保持静止状态。
绑定构造函数参数:未来某个时候f_process_factory
的{{1}}的特化可能需要将构造函数参数传递给t_process
}创建者,但t_process
不想了解它们。
准备依赖注入:可以专门化这些工厂来返回模拟,而不是真正的X
。这可以通过几种方式实现,但不完全一样。
专业对象创建:(这实际上只是前两种情况的一般情况),可能有t_process
的特化在不同情况下创建 - 例如,它可能会根据环境变量或操作系统创建不同的t_process
类型。这将需要工厂的专业化。
如果是我,并且这些听起来都不合理,我可能会把它撕掉,因为它似乎是无偿的设计模式使用。
答案 2 :(得分:1)
嗯,在这种情况下它没有多大意义,除非作者希望将来某个时候更新默认工厂的定义。但是,如果工厂对象作为参数传入,那将是有意义的;工厂为构建对象提供了更大的灵活性,但如果您在使用它的同一个地方实例化工厂,那么它确实没有提供优势。所以,你是对的。