Inheritance in C++ - Where to Use Protected
(Page 4 of 5 )
While inheriting from the base classes, you may be tempted to specify protected access for the base variable members, so you can call them directly in the derived classes. As convenient as this may seem at first, I want to ring the warning bell; this is a dangerous practice, and one that can lead to error nodes and hard-to-maintain code.
Inheritance, to be efficient and software design friendly, should not provide direct access to the base class data. The point of inheritance is to provide services rather than dependency. By this, I mean that it should benefit from the base's functions only.
Suppose you declare a protected member variable in the base class. By definition, all classes derived from it, and friends of those, will have direct access to the variable. You will spare a few lines that you should have written for the get/set functions. Imagine now that you've finished the full hierarchy and implemented it into an application.
After a period, someone comes along, finds the name of the variable inappropriate, and changes it to a new one. Moreover, after this he simply tries to build the application. Countless errors will be generated if he forgot to change the names in the derived classes as well. Changing those is a troublesome task.
In addition, this is only the smaller issue. If you code in this fashion, you will find yourself in a situation where someone has changed the variable at a point and you have no tool with which to catch it.
The way I wrote the class on the first page is the solution. The members should always be private, so no one can access it besides the class itself, offering its services instead through the name and ID function.
The implementation looks like this:
int& GeEntity::ID()
{
return m_ID;
}
const int& GeEntity::ID() const
{
return m_ID;
}
Do it in the same way for the name also. These return the reference to the parameter both non-const and const so you can change and just read the data from the variables. If someone changes its value inappropriately, you can debug it easily by putting a break point inside the non-const call. It is simple and efficient.
Some people say that this will further slow down the application, because it will use a function call for accessing a variable and returning a value, wasting both CPU and memory. However, this is false. Today’s compilers are smart enough to detect get/set functions and reference returns like this, and they will do the optimization.
At the compilation, there is a stage called inliner. This will take all functions that will not increase the size of the build significantly and put them directly inside the application. For instance, you may have a long function, although it is called only at a specific place. We can just take out that segment and put it where it is called, and economize a function call with absolutely no size change.
When you have a long function that is called a million times, for example, we had better leave it, as the extra size generated is too much to pay for. The compilers are once again behaving intelligently, striving to resolve situations like this. This encourages software engineering and a better readability/maintainability of the code.
Next: Constructor, Deconstructor >>
More C++ Articles
More By Gabor Bernat
