Exposing an aggregatee interface

This is probably a silly question, but I'm becoming suspicious I'm not realizing some better design.

On a few cases, I have classes designed with a rich interface being used as aggregatees on other classes:

Code:

---

class CBeing {
    /* ... */
private:
    CInventory inv_;
};

---

CInventory has a well delineated interface. Functions to equip and unequip items, drop and pick them, and much more.

The above example forces me to expose CInventory interface by adding to CBeing interface function members that basically all they do is call inv_ own methods. Only a very small subset of CInventory interface will not be exposed through CBeing. Note this is meant to be an aggregation. inv_ will be destroyed when CBeing is destroyed.

It's not that it shocks me. However, it makes me suspicious that I'm failing to realize some other better choice than carrying over to the aggregator an aggregatee's interface.

Is there?

>Is there?
If you find yourself constantly wrapping the same public interface around members, you might do better with inheritance instead.

hmm... I think you are right. It's not that Being is-a type of Inventory. Being has an Inventory. However... I end up proving the former if I carry over almost all of its interface.

Food for thought... Thanks once again Prelude.

>It's not that Being is-a type of Inventory.
True. There are two schools of thought on this. First, is-a is a .......... to adhere to in the real world. :D Second, if is-a doesn't apply but you think inheritance could simplify your life, chances are good that your owning class' interface could be improved so that instead of just wrapping calls to the owned class' interface, you design an interface that still uses the owned class without duplicating its design. That usually results in more fluid interfaces across the board. It takes a great deal more effort though.

I hear you. I remember browsing some time ago through these issues with the (i think) classic "A penguin is not a bird" OOP discussion.

I'll reconsider how I will be better served. Thanks. :)

>classic "A penguin is not a bird" OOP discussion.
Or rather, all birds don't fly. ;)

Exactly hehe.

But it did bring about the whole issue of not always the code reflecting reality. Is-a and Has-a relationships not being something we really want to draw from the real world all the time.

I've solved problems like this in a variety of ways, this is one possibility as well:

Code:

---


class CBeing {

public:

  class CInventory{
      /* ... */
  } inventory;

private:
  /* ... */
};

---

I also make CInventory's copy constructor and assignment operator private so nobody can directly assign to a CBeing's inventory, but in this way they can use myBeing.inventory.AddItem() and the like.

I'd only do this when the classes were strongly coupled, and the contained class had no purpose except to be a member of the containing class (in this example, I'd only use it if Inventory made no sense if it was separated from a Being).

Public member variables are not universally bad; I tend to avoid them whenever possible for primitives, but a public member object, especially one that cannot be altered with copy construction or assignment, can be used at times, and in general I'd prefer that over a straight duplication of the interface.

Yes. That's a possibility as well. It is a fact CInventory is only going to be used with CBeing. It has no meaning as a standalone class.

The only reason I devised it as a class is that I was confident that I would want one day or another to reuse it. Getting rid of the class altogether and simply merging it into Cbeing is another possibility I'm seriously pondering. CInventory doesn't inherit or derives. It's sole purpose is to exist inside CBeing.

If you wanted to maximize its reuse you could always just make a public member variable of type CInventory. Public member variables don't always break encapsulation; in this case the public interface of the Inventory is part of the public interface of the Being. The Inventory isn't just an implementation detail (which should be hidden), it forms an important part of the public interface (which must be exposed).

If you wanted to couple CInventory to CBeing a little less tightly, and be the most const-correct, you could:
* Make an abstract base class IInventory that describes the Inventory interface,
* Make a private reference to IInventory in CBeing,
* Derive the CInventory from IInventory,
* Make functions IInventory& Inventory() and const IInventory& Inventory() const that merely return the reference.

Quote:

---

Originally Posted by Cat

* Make functions IInventory& Inventory() and const IInventory& Inventory() const that merely return the reference.

---

thats what I would do. Just make a GetInventory() function that returns the interface. Then you can control with friend what classes can change the inventory

The interface is in fact the best option. No need to use friendship though. I would be coupling the classes all the more tighter (which was what the interface was aiming against in the first place).

The solution is perfect because I can hide a very small part of CInventory interface that I don't want visible to CBeing users.

Thanks everyone.