What is the purpose of this code?
I am struggling to understand why the initialization of pprocessor, below, is written like this:
class X
{
...
private:
boost::scoped_ptr<f_process> pprocessor_;
};
X:X()
: pprocessor_( f_process_factory<t_process>().make() ) //why the factory with template
{...}
instead of just writing
X:X()
: pprocessor_( new t_process() )
{...}
Other relevant code is:
class f_process {
...
};
class t_process : public f_process {
...
};
//
cl开发者_StackOverflow中文版ass 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(); }
};
The guy who wrote the code is very clever so perhaps there is a good reason for it.
(I can't contact him to ask)As it is, it seems kinda pointless, but I can think of a few possible uses that aren't shown here, but may be useful in the future:
Memory management: It's possible that at some point in the future the original author anticipated needing a different allocation scheme for
t_process
. For example, he may want to reuse old objects or allocate new ones from an arena.Tracking creation: There may be stats collected by the
f_process_factory
objects when they're created. Maybe the factory can keep some static state.Binding constructor parameters: Perhaps a specialization of the
f_process_factory
fort_process
at some point in the future needs to pass constructor parameters to thet_process
creator, butX
doesn't want to know about them.Preparing for dependency injection: It might be possible to specialize these factories to return mocks, instead of real
t_process
. That could be achieved in a few ways, but not exactly as written.Specialized object creation: (This is really just the general case for the previous two), there may be specializations of
t_process
that get created in different circumstances - for example, it might create differentt_process
types based on environmental variables or operating system. This would require specializations of the factory.
If it were me, and none of these sound plausible, I'd probably rip it out, as it seems like gratuitous design pattern usage.
This look like he is using the factory design pattern to create new instances of t_process. This will allow you to delegate the responsibility of creating different types of t_process away from class X
Well, in this case it doesn't make much sense, unless the author expects the default factory's definition will be updated sometime in the future. It would make sense, though, if the factory object were passed in as a parameter; a factory gives you more flexibility in constructing an object, but if you instantiate the factory at the same place that you use it, then it really doesn't provide an advantage. So, you're right.
精彩评论