Following on a recent thread about exposing the aggregatee interface, I'm faced with a situation I'm not comfortable with and need your opinion.
To bring you back on focus... I have a class CInventory that is a part of CBeing. It was decided then that CInventory would expose its interface through IInventory.
CBeing has a CInventory. It exposes CInventory interface through IInventory. This allowed me to hide a small subset of the CInventory interface I didn't want visible to users of CBeing while still have CInventory fully available to the internals of CBeing.Code:class IInventory { /*... */ } class CInventory: public IInventory { /* ... */ }
And this is where the problems start. You see, I don't want to worry much about the management of the inv_ object. So, it's quiet easy for me to change the above to pointers to CBeing, allocating on the constructor and deallocating on the destructor.Code:class CBeing { public: /* ... */ IInterface& Inventory() { return inv_; } const IInterface& Inventory() const { return inv_; } private: /* ... */ CBeing& inv_; };
However the syntax I will be forcing on the user of CBeing is probably unnecessary. being.Inventory()->equip("sword"); is not pretty when I can have being.Inventory().equip("sword");.
The problem is that the above reference forces me to define CBeing::inv_ on the constructor initializer list. I just think my code smells trouble here...
The problem is that I really don't have an object to feed inv_ with. That object will be created with CBeing and destroyed with it.Code:CBeing::CBeing(): inv_() { inv_.load_dat("00001"); }
With pointers and allocation/deallocation I can solve this. But what can I do if I stick to references?