the evolution path of object factory

In order to perform a modular C++ project, interface and library are widely used.

Let us review the interface first:

class ABCInterface



virtual ~ABCInterface(){}

virtual bool dosomething() = 0;


To implement this interface, we have to provide a way to create as well.

class ABCImpl: public ABCInterface



virtual bool dosomething() override;


ABCInterface CreateABC();

void DestoryABC(ABCInterface* obj);

Thanks linker, and OS loader, they can help automatic loading so/dll who exported the create function.

but if you want to hide the linking procedure,  we can introduce a factory class to manage the create procedure, you can receive an object pointer if you provide the class name(of course, it cannot be perfect, this is c++, it is strong type language).

Let us start reviewing our object factory evolution path:


v 1.0 PluginKernel – yang @ 2010


  1. it loads all dlls from specified folder, and dlls will user global variables to auto register classes.
  2. no need to care where is the class(similar to C++ static linking, but this is dynamic)


  1. it requires application to load dlls at starting, so it takes time, it also no lock inside.
  2. the library is closed-source(some components loaded through this interface are also closed-source), until 2 years later(around 2013). we can got some exception if it got problem. so debugging is a problem sometimes.


class CPluginAutoReg: used to register a class(store create, destory function pointer), usually declare as a global variable

class CCommonPluginAutoReg, class CSingletonPluginAutoReg: wrap class to create object

template class PluginAutoPtr: store the created object, becaue it is a template, you can attach interface when using this template, easier to write final code.

plugkernel apis: these api are used by above classes to register,create.

a snapshot of v 1.0


v 1.1 PluginKernel – yew- yuy @ around 2013

Due to our boss complains the product was too slow, also due to many components are closed source. we added a lock inside pluginkernel after we got pluginkernel project source code. so that we can load some libraries later(to load in a work thread).


  1. add a lock inside this library, so that we can load some libraries in work thread, to improve the product startup speed.
  2.  manually grouped libraries into two. one of them are loaded in a work thread.

v 2.0 objmanager – xiaole @ Sep 2014

This project is made due to a product is under re-construction.


  1. it added dll name in the object. so a class name was changed from ‘someclass’ to ‘somedll@someclass’. this is a great improvement. no longer need to pre-load dlls, we can load dll when creating objects on demand


  1. no longer require to pre-load all dll files


  1. you need to take care raw pointers when creating/destroying


class objregister: the wrap class for registration

template class objregisterImp: it is used to store create,destroy function.

class ObjManager: it is the factory for creating objects, it stores all creating/destroy function point.

v 2.1 – xiaole

moved the code to a higher level project, no functional change

v 2.2 baseobj – yuy


  1. added a base class baseobj, it requires classes to derive from this
  2. added a template class ObjPtr, it works similar to a shared_ptr
  3. ObjManager is renamed to ObjHost


  1. based on v 2.0/2.1, v 2.2 has a template class to make coding easier.


  1. it requires classes  to derive from the new class.

v 2.3 yuy

minor change from v 2.2:

  1. added isNull, isValid for pointer checking

v 2.4 jian ann

the v 2.1/v2.2 has ObjPtr class, but it couldn’t manage object properly. so jian ann and yew from another team gave a hand to review the code.

in v 2.4 ObjPtr is removed, added a template function MakeObject, and using shared_ptr destructor to handle cleaning task


  1. ObjPtr is replaced with stared_ptr, using MakeObject to create objects.


  1. it solved crash introduced in v 2.1

v 2.5 jian ann


  1. add a mutex inside ObjManager, now it is thread-safe


  1. solved the multi-thread issue inside ObjManager

v 2.6 yew


  1. added singleton support
  2. added reference counting to dll, we can release a dll when no object is active now. we need this because many objects are global/static, they will be recycled until a dll is unloaded

v 2.7 (the current in use version, contains all changes after 2.6)


  1. added more log for troubleshooting
  2. release all dlls when ObjHost is going to destroy

a snapshot of v 2.x






v 3.0 (maybe) objbase – yew @ dec 2016

it is the end of 2016, after more than 2 years development, the product plans to release, due to many crashes, need to review code again. partially due to hasn’t touched this project for about 2 years, jian ann felt the code is over-engineered, hard to debug. Because similar classes are the foundation of the product, used in many places, not easy to make a change.

After revamping some other components, yew  decided to rewrite this. Because we have very clear requirement now. and it is the time to use more modern language features.


  1. only one header file, and one class ‘ObjBase’, it uses shared_ptr and lambda expression to store data and carry out cleaning logic
  2. provided compatible macros with v 2.7, so application code can remain unchanged


  1. more clean implementations
  2.  supports full features included in v 2.7

a snapshot of v 3.0




you can get v3 source code from here:



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s