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

看起来他正在使用factory design pattern来创建t_process的新实例。这将允许您将创建不同类型的t_process的责任委托给X类

Answer 2

实际上，它看起来有点毫无意义，但我可以想到一些未在此处展示的可能用途，但在将来可能会有用：

内存管理：在未来的某个时刻，原作者可能会预期t_process需要不同的分配方案。例如，他可能想要重用旧对象或从竞技场中分配新对象。
跟踪创建： f_process_factory个对象在创建时可能会收集统计信息。也许工厂可以保持静止状态。
绑定构造函数参数：未来某个时候f_process_factory的{{1}}的特化可能需要将构造函数参数传递给t_process }创建者，但t_process不想了解它们。
准备依赖注入：可以专门化这些工厂来返回模拟，而不是真正的X。这可以通过几种方式实现，但不完全一样。
专业对象创建：（这实际上只是前两种情况的一般情况），可能有t_process的特化在不同情况下创建 - 例如，它可能会根据环境变量或操作系统创建不同的t_process类型。这将需要工厂的专业化。

如果是我，并且这些听起来都不合理，我可能会把它撕掉，因为它似乎是无偿的设计模式使用。

Answer 3

嗯，在这种情况下它没有多大意义，除非作者希望将来某个时候更新默认工厂的定义。但是，如果工厂对象作为参数传入，那将是有意义的;工厂为构建对象提供了更大的灵活性，但如果您在使用它的同一个地方实例化工厂，那么它确实没有提供优势。所以，你是对的。

这段代码的目的是什么？

3 个答案: