References vs information hiding C++

Question

Hi,

I need suggestions on how to solve the type of problems described below. I'm fairly new at C++ and OO-design.

I've learnt:

1. Pointers shall be avoided when ever they can be replaced by references.
2. Objects shall have no knowledge of objects that they don't need to know about.

But when creating objects having references to other objects we must pass these references as input arguments to the constructor. Thus we need to know about objects we should not not know anything about.

But look at the following example:

• Suppose I have a object "Menu" that needs to have it's own timer object "Timer". I'd like to implement this association as a reference.

• The object MenuHandler aggregates a lot of Menu objects but shall not have any knowledge about Timer objects. But when the MenuHandler creates a Menu object it must pass a Timer reference argument to the constructor. Thus, **MenuHandler must know about Timer**.

Any suggestions on how to treat these kind of problems?

Answer 1

Why not simply make the Timer object a member (by value) of the Menu class?

Answer 2

I find that I produce better (more maintainable, faster, etc) code and that I'm more productive using references in C++ than I would be solving the same problem with pointers... I think the traditional answer to your example would be to have a factory object that creates menus. In this way, the MenuHandler doesn't need to know about the Timer class.

Answer 3

The MenuHandler creates a Timer object, passes it into the Menu constructor, and forgets about it. That seems entirely reasonable.

If the MenuHandler unnecessarily kept a reference to the Timer, that would be against the advice point #2.

Answer 4

I'd hesitate to bless your choice of words when it comes to the two numbered points. They're a sign you're on the right way learning C++, but they might be misleading to other novices. When I take a look at your concrete examples, this becomes more obvious.

A MenuHandler should not create menus. The content of menus is determined by by the application, so the application object (or the Controller part, if you've implemented Model-View-Controller) should create menus. The MenuHander merely takes ownership of menus created elsewhere.

Also, it may make sense to give each menu its own timer. That means the relation can be described as "Has a"; the menu has a timer. The relationship usually implmented by references can be described as "Knows a" (the inheritance relationship is usally called "Is a"). If each Menu object has a Timer, it can be a member, and initialized by the Menu constructor(s). The Timer object internally may obtain a reference to the system clock in its constructor, but that's not your concern.

Answer 5

In a more general case where you need to provide a class to another class in order to do some kind of callback, you avoid mutual dependency (both know each other) by using an interface. Class A derives from the interface. Class B accepts the interface as paramater in the constructor and calls the virtual function from that interface when needed. Also check the observer design pattern.

Answer 6

For #1 Be very careful with the lifetime of your objects. References are no that suitable to handle dynamic graph of objets ( like your menu, menuhandler, timer, etc... ). What if you want to change the timer object later ?

It's not a good idea to have references as members in a class if the lifetime of referenced objects is not really known.

Avoiding pointer does not mean using references everywhere, you should have a look at smart pointers which will be more suitable for what you want to do.