Class Interface Request

Question

I was wondering what design I have been using for quite some time for my game engine and games. Let them say that we have an Object class

class Object { public: const std::string& getName() { return m_name; } private: std::string m_name; } 

Then I have an ObjectManager class that contains an instance of Object. Now I was wondering if I should store this instance in the ObjectManager and duplicate the code so that it could call getName (), or make an Object public that defeats the concept of encapsulation. Which design do you guys think better?

Thanks for any help!

Answer 1

If your class contains an object that can be used by others, expose it. Encapsulation is designed to hide the variables needed for something. Some data members do not fall into this.

Example:

Volume man;

  tom.getEyes().getColor(); tom.getMouth().eat(tomato); tom.legs().walk(); 

A person could hide everything, but that would be cumbersome:

  tom.getEyesColor(); // accessor for every eye feature tom.eat(tomato); tom.walkAndEat(); // every possible combination of actions 

Further example:

  grid.row(3).col(5).setText("hello"); 

Here a column class can expose many methods without the need for a grid class. This is the beauty of object-oriented programming.

If you named your class ObjectManager, I realized that it manages the object instances for others, so you have to expose it. Another idea to use inheritance is also valid:

  class ObjectManager : public Object { }; 

Answer 2

If you want to restrict the interface to methods only, then save the private object and use the accessor method, which returns a reference link const (and not const const) to the private object.

In addition, inheritance is a good option, if applicable.

Answer 3

It depends on what you do. If I understood your question correctly, I would be more inclined to make Object a private member of ObjectManager and add the ObjectManager function as a proxy for Object :: getName (). (Is this your question?) However, if you just wrap especially thinly and are not trying to do something especially technical or what you have, I may be tempted to answer otherwise. It depends, but more than likely, go ahead, make it private and add an extra feature. Please note that this answer is based on the assumption that you are going to use it as a legacy here.

Answer 4

It really depends on the situation (Sorry for the non-response!). If you want to support strong encapsulation, you probably want the ObjectManager to look something like this:

 public class ObjectManager { private: Object obj; public: string GetNameOfInnerObject(); } 

As you can see, I changed the method title as descriptive with respect to the ObjectManager. This type of method name can come in handy to abstract the object from more complex interactions within itself.

Edit: this can help if you tell us what the ObjectManager should do. Are there any methods that do not match your internal object?