home account info subscribe login search FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
[an error occurred while processing this directive]
Previous Table of Contents Next


How It Works

Each of the object-oriented terms previously defined will be expanded on in the How-Tos that follow.

Comments

This How-To provided brief definitions of commonly used terminology in object-oriented programming.

2.2 Learn the concept of inheritance so that I can apply it programmatically?

Problem

I’ve been learning to write basic C++ programs using a structured methodology and am ready to learn the principles of object-oriented programming. I want to be able to put these principles into practice using the C++ language. I have heard that inheritance is one principle of object-oriented programming. How can I understand the concept?

Technique

The principles of object-oriented programming can be learned with minimal effort. The three basic concepts of object-orientation are inheritance, encapsulation, and polymorphism. Understanding inheritance is a good starting point because it is an easy concept to grasp.

The technique used to apply inheritance is straightforward. Think about your family tree—that is inheritance. The procedure to describe your family tree is the same to describe class inheritance in C++ (or any other object-oriented language, for that matter).

Inheritance is known as an is-a relationship. A golden retriever is-a dog, a snake is-a reptile, and a flower is-a plant. Each of these is a specialization of its parent. For example, although a snake and a lizard are both reptiles, they are very different from each other.

To begin applying inheritance, you must decide the base classes that must exist within your application. Those base classes provide basic, default functionality to users of the class. Users, in this context, relate to other objects within your application that create and use instances of the classes you have declared. An instance of a class is also referred to as an object; it is something that “lives and breathes” within your program. An object exists and performs operations upon itself and other collaborating objects. Think of it this way: A blueprint for a building is analogous to a class. The building is the object. The blueprint is just the static representation of the building. The building is the dynamic, living object.

The interface of a class is the part that the clients see. An interface is considered a contract the class has with its clients. For example, an automobile has an interface (contract) with its driver. An automobile’s interface includes a steering wheel, gas and brake pedals, speedometer, and possibly a clutch and stick shift. This interface provides functionality to you, the driver. Yet, you don’t have to know anything about the inner workings of the automobile—you just put the key in, turn it, and drive off. The only functionality you have to worry about is steering, braking, and resuming speed. To you, it does not matter if the car has front-wheel or rear-wheel drive, or if the engine is a four- or eight-cylinder; you just want the car to get you to your destination.

All objects you interact with have the concept of interface. Even the simplest thing, such as a television or room light, has an interface. The television’s interface consists of buttons or dials and the interface of a room light is an on/off switch. With the television, all you have to do is to push buttons or turn dials; you do not have to understand electrical circuitry to operate it.

The first step to create a class is to identify the interface that the class must present to its users. Let’s proceed through the process using a step-by-step guide to develop a simple hierarchy.

First, for this chapter, I would like to stay away from implementing object-oriented concepts using the C++ language. The next chapter will address how to use the C++ language to implement the object-oriented concepts learned in this chapter.

Second, no special software tool is required for this chapter. The only requirement is that you learn to think in an object-oriented way. You might want to use a text editor (or even longhand) to capture your class descriptions and inheritance hierarchies.

Let’s create our own object-oriented declarative language. A simple language is in order. The following is a glossary of our language:

  thing—The entity that is described. A thing is analogous to a class (refer to How-To 2.1). A thing can have an interface that users can utilize. A thing will have a name associated with it. A thing can be a superthing, a subthing, or just a thing by itself. A thing will have parts and services, both visible and hidden from users of the thing.
  descendantOf—A keyword that describes that some thing is a descendant of some other thing. For example, you are a descendantOf your mother and father.
  part—Used to describe the data to be used by a thing. A part is equivalent to an attribute (refer to How-To 2.1). A thing must have data to represent its current state.
  service—An implementation for an operation of a thing. It is defined by functionality provided by a thing to fulfill its interface (contract) to users.
  exposed—Available to the outside world (to client objects using this object). Using a thing’s name, an object can access a thing’s part directly.
  internal—The opposite of exposed. Only the thing itself can access its part element(s). A thing must provide a service so that client code can either change or get the value of a thing’s part.
  inherit—This data is accessible by the thing directly and is inherited by its descendants for access. For example, if child is a descendant of parent, child will receive a copy of parent’s parts.
  superthing—A parent thing. Within a parent-child relationship, the parent is the superthing.
  subthing—A child thing. Within a parent-child relationship, the child is the subthing.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-1999 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.