26.5 Objects

I l @ ve RuBoard

So far our discussion has been focused on procedures. That's because procedures are one of the basic building blocks of a program. The other major piece of the puzzle is data structures. Combine the two and you have an object.

The design guidelines for a simple object are much like the ones for a module. You want to create a simple interface, hide as much information as possible, and keep the interconnects between objects to a minimum.

But objects give us one big advantage over the simple data structure/module design. With simple modules, your view of the data is limited. You either see the whole structure or you don't. Thus it's not possible (without getting very tricky) to write a procedure that accesses the common elements of several different types of data structures.

Perhaps an example will explain this better. On the weekends, I'm a real engineer at the Poway-Midland Railroad. There are three major types of locomotives: steam , diesel , and electric. They have some attributes in common; they all pull trains, for example. But there are some attributes unique to each locomotive. For example, only a steam engine requires lots of water to operate .

Using simple data structures, it's impossible to design a single data structure that encompasses all three locomotive types without wasting space. For example, the following structure describes all three types of locomotives ”not well, but it does describe them: ^[2]

^[2] I know that there are steam locomotives that burn things other than coal, but for the purposes of this example, I'm simplifying the universe and steam engines burn only coal.

 struct locomotive {     bool running;   // Is the locomotive running     int speed;      // Speed in MPH     int num_cars;   // Number of cars it can pull     int water;      // Water consuption in gallons / hour                     // [Steam engine only]     int coal;       // Coal used in tons / hour                     // [Steam only]     int diesel_oil;  // Oil consumed in gallons / hour                     // [Diesel only]     // .. rest of the data }; 

Arranging data in this way is neither simple nor efficient. Objects let you arrange data in a new way by letting you create a general base object and derive more complex objects from it.

For example:

 class generic_locomotive {         public:             bool running;       // Is the locomotive running             int speed;          // Speed in MPH             int num_cars;       // Number of cars it can pull             // ... rest of the data     };     class steam_engine: public generic_locomotive {         public:             int water;  // Water consuption in gallons / hour                         // [Steam engine only]             int coal;   // Coal used in tons / hour                         // [Steam only]      };          class diesel_locomotive: public generic_locomotive {         public:             int diesel_oil;      // Oil consumed in gallons / hour                                  // [Diesel only]             // .. rest of the data    };               class electrice_motor : public generic_locomotive {         public:             // Electric Locomotives aren't that complex             // .. rest of the data    }; 

This data organization gives us tremendous flexibility. We are no longer constrained to writing procedures that deal with data structures as whole. Instead, procedures that want to deal with a generic locomotive can deal with the data type class locomotive . Other procedures that are locomotive-type-dependent can deal with their type of locomotive.

So our procedures can deal with the data at different levels. Thus with derived objects we've created different views into our data.

This is a good example of information hiding. Functions that deal with generic locomotives don't have to know about the specifics of each engine. They deal only with the generics. Figure 26-4 shows this information layering technique.

Figure 26-4. Layers of information

One of the nice things about virtual member functions is that they aid in information hiding. They provide an interface that is seen in the base class, but whose specifics reside in the derived class.

26.5.1 Interfaces and C++ Classes

Ideally, when you publish an interface you want to publish only the public data. In C++, to publish the interface for a class, you include the class definition in a header file. There is a problem, however; the class definition includes both public and private data.

This can cause problems.

Let's go back to our machine tool example. We had a hardware support module; it's a published interface (header file). For testing, we replaced it with a hardware simulation module that used the same published interface (the exact same header file).

When the interface is a class, you can't do that. That's because your hardware support class will probably have different private members than the simulation support class. Thus you need to keep two header files around, one for the hardware module and one for the simulation.

The public information in these header files must be duplicated , and thus you have all the problems associated with trying to keep two different files up to date and synchronized.

Unfortunately, C++ is not perfect, and the fact that private information must be published is one of its big problems.

In any design, the architect must make a number of trade-offs and compromises. In the case of C++, it was designed to be mostly compatible with the older C language. The designer, Bjarne Stroustrup, also wanted something that could be compiled using the technology of the time (early 1980s).

It was these factors that led him to design classes the way they are. Unfortunately, as a side effect of this design, interface and implementation information were both forced into the class definition.

But given the circumstances under which he worked, Mr. Stroustrup did a brilliant job of creating a new language, in spite of any rough spots which may appear .

I l @ ve RuBoard