[19] Inheritance — basics
(Part of C++ FAQ Lite, Copyright © 1991-2006, Marshall Cline, cline@parashift.com)

FAQs in section [19]:

[19.1] Is inheritance important to C++?

Yep.

Inheritance is what separates abstract data type (ADT) programming from OO programming.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.2] When would I use inheritance?

As a specification device.

Human beings abstract things on two dimensions: part-of and kind-of. A Ford Taurus is-a-kind-of-a Car, and a Ford Taurus has-a Engine, Tires, etc. The part-of hierarchy has been a part of software since the ADT style became relevant; inheritance adds "the other" major dimension of decomposition.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.3] How do you express inheritance in C++?

By the : public syntax:

 class Car : public Vehicle {
 public:
   ...
 };

We state the above relationship in several ways:

(Note: this FAQ has to do with public inheritance; private and protected inheritance are different.)

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.4] Is it OK to convert a pointer from a derived class to its base class?

Yes.

An object of a derived class is a kind of the base class. Therefore the conversion from a derived class pointer to a base class pointer is perfectly safe, and happens all the time. For example, if I am pointing at a car, I am in fact pointing at a vehicle, so converting a Car* to a Vehicle* is perfectly safe and normal:

 void f(Vehicle* v);
 void g(Car* c) { f(c); }  // Perfectly safe; no cast

(Note: this FAQ has to do with public inheritance; private and protected inheritance are different.)

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.5] What's the difference between public, private, and protected?

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.6] Why can't my derived class access private things from my base class?

To protect you from future changes to the base class.

Derived classes do not get access to private members of a base class. This effectively "seals off" the derived class from any changes made to the private members of the base class.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.7] How can I protect derived classes from breaking when I change the internal parts of the base class?

A class has two distinct interfaces for two distinct sets of clients:

Unless you expect all your derived classes to be built by your own team, you should declare your base class's data members as private and use protected inline access functions by which derived classes will access the private data in the base class. This way the private data declarations can change, but the derived class's code won't break (unless you change the protected access functions).

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.8] I've been told to never use protected data, and instead to always use private data with protected access functions. Is that a good rule?

Nope.

Whenever someone says to you, "You should always make data private," stop right there — it's an "always" or "never" rule, and those rules are what I call one-size-fits-all rules. The real world isn't that simple.

Here's the way I say it: if I expect derived classes, I should ask this question: who will create them? If the people who will create them will be outside your team, or if there are a huge number of derived classes, then and only then is it worth creating a protected interface and using private data. If I expect the derived classes to be created by my own team and to be reasonable in number, it's just not worth the trouble: use protected data. And hold your head up, don't be ashamed: it's the right thing to do!

The benefit of protected access functions is that you won't break your derived classes as often as you would if your data was protected. Put it this way: if you believe your users will be outside your team, you should do a lot more than just provide get/set methods for your private data. You should actually create another interface. You have a public interface for one set of users, and a protected interface for another set of users. But they both need an interface that is carefully designed — designed for stability, usability, performance, etc. And at the end of the day, the real benefit of privatizing your data (including providing an interface that is coherent and, as much as possible, opaque) is to avoid breaking your derived classes when you change that data structure.

But if your own team is creating the derived classes, and there are a reasonably small number of them, it's simply not worth the effort: use protected data. Some purists (translation: people who've never stepped foot in the real world, people who've spent their entire lives in an ivory tower, people who don't understand words like "customer" or "schedule" or "deadline" or "ROI") think that everything ought to be reusable and everything ought to have a clean, easy to use interface. Those kinds of people are dangerous: they often make your project late, since they make everything equally important. They're basically saying, "We have 100 tasks, and I have carefully prioritized them: they are all priority 1." They make the notion of priority meaningless.

You simply will not have enough time to make life easy for everyone, so the very best you can do is make life easy for a subset of the world. Prioritize. Select the people that matter most and spend time making stable interfaces for them. You may not like this, but everyone is not created equal; some people actually do matter more than others. We have a word for those important people. We call them "customers."

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[19.9] Okay, so exactly how should I decide whether to build a "protected interface"?

Three keys: ROI, ROI and ROI.

Every interface you build has a cost and a benefit. Every reusable component you build has a cost and a benefit. Every test case, every cleanly structured thing-a-ma-bob, every investment of any sort. You should never invest any time or any money in any thing if there is not a positive return on that investment. If it costs your company more than it saves, don't do it!

Not everyone agrees with me on this; they have a right to be wrong. For example, people who live sufficiently far from the real world act like every investment is good. After all, they reason, if you wait long enough, it might someday save somebody some time. Maybe. We hope.

That whole line of reasoning is unprofessional and irresponsible. You don't have infinite time, so invest it wisely. Sure, if you live in an ivory tower, you don't have to worry about those pesky things called "schedules" or "customers." But in the real world, you work within a schedule, and you must therefore invest your time only where you'll get good pay-back.

Back to the original question: when should you invest time in building a protected interface? Answer: when you get a good return on that investment. If it's going to cost you an hour, make sure it saves somebody more than an hour, and make sure the savings isn't "someday over the rainbow." If you can save an hour within the current project, it's a no-brainer: go for it. If it's going to save some other project an hour someday maybe we hope, then don't do it. And if it's in between, your answer will depend on exactly how your company trades off the future against the present.

The point is simple: do not do something that could damage your schedule. (Or if you do, make sure you never work with me; I'll have your head on a platter.) Investing is good if there's a pay-back for that investment. Don't be naive and childish; grow up and realize that some investments are bad because they, in balance, cost more than they return.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

E-Mail E-mail the author
[ C++ FAQ Lite | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised Mar 1, 2006