Question

Consider the following code:

class Rectangle
{
public:
    // Constructors
    Rectangle(){ init(0,0); }
    Rectangle(int h, int w){ init(h,w); }

    // Methods
    void init(int h, int w)
    {
        _h = h;
        _w = w;
    }

    // Getters / Setters
    double get_h(void){ return _h; }
    double get_w(void){ return _w; }
    void set_h(double h){ _h = h;  }
    void set_w(double w){ _w = w;  }
    std::string get_name(void){ return _name; }
    void set_name(std::string name){ _name = name; }

private:
    // Private Members
    int _h, _w;
    std::string _name;
};

class House
{
public: 
    // <BEGIN PASSTHROUGHS>
    std::string get_b_name(void){ return _base.get_name() };
    std::string get_r_name(void){ return _roof.get_name() };
    void set_b_name(std::string name){ _base.set_name(name); }
    void set_r_name(std::string name){ _roof.set_name(name); }
    // </END PASSTHROUGHS>

private:
    // Private Members
    Rectangle _base;
    Triangle  _roof;
};

This code works fine.

My question deals with the “passthrough” functions in the House class, enclosed by the PASSTHROUGHS tags. Is this the best way to do this? The arguments and return types will always match and there is no “intelligence” in these passthrough functions other than to make things cleaner and more straightforward.

My instinct would be something like one of the following:

get_b_name = _base.get_name;

// OR

std::string get_b_name(void) = _base.get_name;

… but neither seem to work unfortunately and it was only wishful thinking in the first place. If there are no easier options, telling me that is fine too. Thanks!

Answer 1

The problem, I think, is conceptual. Your design is quite un-object oriented in that the house does not represent an entity, but rather provides a bit of glue around the components. From that standpoint, it would make more sense to provide accessors to the elements, rather than pass-through functions:

class House {
   Rectangle _base;
   Triangle  _roof;
public:
   const Rectangle& base() const {
      return _base;
   }
   const Triangle& roof() const {
      return _roof;
   }
};

I imagine that this is just a toy example, but the same reasoning applies: a class should represent an entity on which a set of operations are preformed, in some cases those operations might be implemented in terms of internal subobjects, but they are still operations on the type, and how they are gathered is an implementation detail.

Consider:

class House {
   Thermostat t;
public:
   int temperature() const {
      return t.temperature();
   }
};

From the user point of view the house has a temperature that can be read, and in this particular implementation, it is read from a thermostat that is a member. But that is an implementation detail. You might want to later install more thermostats in the house and substitute the single reading by an average of the readings, but that will not change the fact that the entity House (in this model) has a temperature.

That is, you should not be thinking in implementing pass-through functions, but rather on implementing features of the type. If the implementation happens to be a single forwarding to an internal method, that is fine.

But if the type contains internal members and it makes sense to access properties of the members, consider that it might be that you actual type should just provide access to its internal members. Consider that you want to move a piano inside the house, then you might just provide access to the door member and let the user check:

class House {
   Door d;
public:
   Door const & door() const {
      return d;
   }
};
bool can_enter_piano( House const & h, Piano const & p ) {
   return h.door().width() > p.size();
}

There is no need to provide House::get_door_width(), and House::get_door_color() so that you can describe the entrance to a friend, and House::get_door_handle() so that they can know when they arrive…