04.01.2015 Views

Thinking in C++ 2nd ed Volume 1 Revision 6

Thinking in C++ 2nd ed Volume 1 Revision 6

Thinking in C++ 2nd ed Volume 1 Revision 6

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

design is that it’s too simple to get from the beg<strong>in</strong>n<strong>in</strong>g to the end. A<br />

m<strong>in</strong>d tra<strong>in</strong><strong>ed</strong> to look for complex solutions is often stump<strong>ed</strong> by this<br />

simplicity at first.<br />

When you <strong>in</strong>herit from an exist<strong>in</strong>g type, you create a new type. This<br />

new type conta<strong>in</strong>s not only all the members of the exist<strong>in</strong>g type<br />

(although the private ones are hidden away and <strong>in</strong>accessible), but<br />

more importantly it duplicates the <strong>in</strong>terface of the base class. That<br />

is, all the messages you can send to objects of the base class you can<br />

also send to objects of the deriv<strong>ed</strong> class. S<strong>in</strong>ce we know the type of a<br />

class by the messages we can send to it, this means that the deriv<strong>ed</strong><br />

class is the same type as the base class. In the above example, “a<br />

circle is a shape.” This type equivalence via <strong>in</strong>heritance is one of the<br />

fundamental gateways <strong>in</strong> understand<strong>in</strong>g the mean<strong>in</strong>g of objectorient<strong>ed</strong><br />

programm<strong>in</strong>g.<br />

S<strong>in</strong>ce both the base class and deriv<strong>ed</strong> class have the same <strong>in</strong>terface,<br />

there must be some implementation to go along with that <strong>in</strong>terface.<br />

That is, there must be some code to execute when an object receives<br />

a particular message. If you simply <strong>in</strong>herit a class and don’t do<br />

anyth<strong>in</strong>g else, the methods from the base-class <strong>in</strong>terface come right<br />

along <strong>in</strong>to the deriv<strong>ed</strong> class. That means objects of the deriv<strong>ed</strong> class<br />

have not only the same type, they also have the same behavior,<br />

which isn’t particularly <strong>in</strong>terest<strong>in</strong>g.<br />

You have two ways to differentiate your new deriv<strong>ed</strong> class from the<br />

orig<strong>in</strong>al base class. The first is quite straightforward: you simply<br />

add brand new functions to the deriv<strong>ed</strong> class. These new functions<br />

are not part of the base class <strong>in</strong>terface. This means that the base<br />

class simply didn’t do as much as you want<strong>ed</strong> it to, so you add<strong>ed</strong><br />

more functions. This simple and primitive use for <strong>in</strong>heritance is, at<br />

times, the perfect solution to your problem. However, you should<br />

look closely for the possibility that your base class might also ne<strong>ed</strong><br />

these additional functions. This process of discovery and iteration<br />

of your design happens regularly <strong>in</strong> object-orient<strong>ed</strong> programm<strong>in</strong>g.<br />

1: Introduction to Objects 51

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!