Looking for a better C++ class factory

前端 未结 10 750
伪装坚强ぢ
伪装坚强ぢ 2020-12-29 00:40

I have an application that has several objects (about 50 so far, but growing). There is only one instance of each of these objects in the app and these instances get shared

10条回答
  •  忘掉有多难
    2020-12-29 01:12

    The way I would solve this problem is using what I would call the Static Registry Pattern, which in my mine mind is the C++ version of dependency injection.

    Basically you have a static list of builder objects of a type that you use to build objects of another type.

    A basic static registry implementation would look like:

    template 
    class StaticRegistry
    {
    public:
        typedef std::list   Container;
    
        static  StaticRegistry&  GetInstance()
        {
            if (Instance == 0)
            {
                Instance = new StaticRegistry;
            }
            return *Instance;
        }
    
        void    Register(T* item)
        {
            Items.push_back(item);
        }
    
        void    Deregister(T* item)
        {
            Items.remove(item);
            if (Items.empty())
            {
                delete this;
                Instance = 0;
            }
        }
    
        typedef typename Container::const_iterator  const_iterator;
    
        const_iterator begin() const
        {
            return Items.begin();
        }
    
        const_iterator end() const
        {
            return Items.end();
        }
    
    protected:
        StaticRegistry() {}
        ~StaticRegistry() {}
    
    private:
        Container               Items;
    
        static StaticRegistry*   Instance;
    };
    
    template 
    StaticRegistry* StaticRegistry::Instance = 0;
    

    An implementation of BrokeredObjectBuilder could look like this:

    class BrokeredObjectBuilderBase {
    public:
        BrokeredObjectBuilderBase() { StaticRegistry::GetInstance().Register(this); }
        virtual ~BrokeredObjectBuilderBase() { StaticRegistry::GetInstance().Deregister(this); }
    
        virtual int GetInterfaceId() = 0;
        virtual BrokeredObject* MakeBrokeredObject() = 0;
    };
    
    
    template
    class BrokeredObjectBuilder : public BrokeredObjectBuilderBase {
    public:
        BrokeredObjectBuilder(unsigned long interface_id) : m_InterfaceId(interface_id) { } 
        virtual int GetInterfaceId() { return m_InterfaceId; }
        virtual T* MakeBrokeredObject() { return new T; }
    private:
        unsigned long m_InterfaceId;
    };
    
    
    class TypeA : public BrokeredObject
    {
       ...
    };
    
    // Create a global variable for the builder of TypeA so that it's 
    // included in the BrokeredObjectBuilderRegistry
    BrokeredObjectBuilder TypeABuilder(TypeAUserInterfaceId);
    
    typedef StaticRegistry BrokeredObjectBuilderRegistry;
    
    BrokeredObject *GetObjectByID(int id)
    {
      BrokeredObject *pObject(0);
      ObjectMap::iterator = m_objectList.find(id);
      // etc.
      if(found) return pObject;
    
      // not found, so create
      BrokeredObjectBuilderRegistry& registry(BrokeredObjectBuilderRegistry::GetInstance());
      for(BrokeredObjectBuilderRegistry::const_iterator it = registry.begin(), e = registry.end(); it != e; ++it)
      {
        if(it->GetInterfaceId() == id)
        {
          pObject = it->MakeBrokeredObject();
          break;
        }
      }
    
      if(0 == pObject)
      {
        // userinterface id not found, handle this here
        ...
      }      
    
      // add it to the list
      return pObject;
    }
    

    Pros:

    • All the code that knows about creating the types is seperated out into the builders and the BrokeredObject classes don't need to know about it.
    • This implementation can be used in libraries and you can control on a per project level what builders are pulled into a project using a number of different techniques.
    • The builders can be as complex or as simple (like above) as you want them to be.

    Cons:

    • There is a wee bit of infrastructure involved (but not too much).
    • The flexability of defining the global variables to include what builders to include in your project does make it a little messy to work with.
    • I find that people find it hard to understand this pattern, I'm not sure why.
    • It's sometimes not easy to know what is in the static registry at any one time.
    • The above implementation leaks one bit of memory. (I can live with that...)

    The above implementation is very simple, you can extend it in lots of different ways depending on the requirements you have.

提交回复
热议问题