C++ For Dummies (2014)

Part III

Introduction to Classes

Visit www.dummies.com/extras/cplusplus for great Dummies content online.

In this part…

· Reviewing object-oriented programming

· Declaring and defining class members

· Declaring constructors and destructors

· Defining static member functions

· Visit www.dummies.com/extras/cplusplus for great Dummies content online

Chapter 11

Examining Object-Oriented Programming

In This Chapter

Making nachos

Reviewing object-oriented programming

Introducing abstraction and classification

Discovering why object-oriented programming is important

What, exactly, is object-oriented programming? Object-oriented programming, or OOP as those in the know prefer to call it, relies on two principles you learned before you ever got out of Pampers: abstraction and classification. To explain, let me tell you a little story.

Abstracting Microwave Ovens

Sometimes when my son and I are watching football (which only happens when my wife can’t find the switcher), I whip up a terribly unhealthy batch of nachos. I dump some chips on a plate, throw on some beans, cheese, and lots of jalapeños, and nuke the whole mess in the microwave oven for five minutes. To use my microwave, I open the door, throw the stuff in, and punch a few buttons. After a few minutes, the nachos are done.

Now think for a minute about all the things I don’t do to use my microwave:

· I don’t rewire or change anything inside the microwave to get it to work. The microwave has an interface — the front panel with all the buttons and the little time display — that lets me do everything I need to do.

· I don’t have to reprogram the software used to drive the little processor inside my microwave, even if I cooked a different dish the last time I used the microwave.

· I don’t look inside my microwave’s case.

· Even if I were a microwave designer and knew all about the inner workings of a microwave, including its software, I would still use it the same way to heat my nachos without thinking about all that stuff inside.

These are not profound observations. You can deal with only so much stress in your life. To reduce the number of things that you deal with, you work at a certain level of detail.

In object-oriented (OO) computerese, the level of detail at which you are working is called the level of abstraction. To introduce another OO term while I have the chance, I abstract away the details of the microwave’s innards.

When I’m working on nachos, I view my microwave oven as a box. (I can’t worry about the innards of the microwave oven and still follow the Cowboys on the tube.) As long as I operate the microwave only through its interface (the keypad), there should be nothing I can do to

· Cause the microwave to enter an inconsistent state and crash.

· Turn my nachos into a blackened, flaming mass.

· Make the microwave (along with the surrounding house) burst into flames!

Preparing functional nachos

Suppose that I were to ask my son to write an algorithm for how Dad makes nachos. After he understood what I wanted, he would probably write “open a can of beans, grate some cheese, cut the jalapeños,” and so on. When it came to the part about microwaving the concoction, he would write something like “cook in the microwave for five minutes.”

That description is straightforward and complete. But it’s not the way a functional programmer would code a program to make nachos. Functional programmers live in a world devoid of objects such as microwave ovens and other appliances. They tend to worry about flow charts with their myriad functional paths. In a functional solution to the nachos problem, the flow of control would pass through my finger to the front panel and then to the internals of the microwave. Pretty soon, flow would be wiggling around through complex logic paths about how long to turn on the microwave tube and whether to sound the “come and get it” tone.

In a world like this, it’s difficult to think in terms of levels of abstraction. There are no objects, no abstractions behind which to hide inherent complexity.

Preparing object-oriented nachos

In an object-oriented approach to making nachos, I would first identify the types of objects in the problem: chips, beans, cheese, and an oven. Then I would begin the task of modeling these objects in software, without regard to the details of how they will be used in the final program.

While I am doing this, I’m said to be working (and thinking) at the level of the basic objects. I need to think about making a useful oven, but I don’t have to think about the logical process of making nachos yet. After all, the microwave designers didn’t think about the specific problem of my making a snack. Rather, they set about the problem of designing and building a useful microwave.

After the objects I need have been successfully coded and tested, I can ratchet up to the next level of abstraction. I can start thinking at the nacho-making level, rather than the microwave-making level. At this point, I can pretty much translate my son’s instructions directly into C++ code.

Classifying Microwave Ovens

Critical to the concept of abstraction is that of classification. If I were to ask my son, “What’s a microwave?” he would probably say, “It’s an oven that …” If I then asked, “What’s an oven?” he might reply, “It’s a kitchen appliance that …” (If I then asked, “What’s a kitchen appliance?” he would probably say, “Why are you asking so many stupid questions?”)

The answers my son gave to my questions stem from his understanding of our particular microwave as an example of the type of things called microwave ovens. In addition, my son sees microwave ovens as just a special type of oven, which itself is just a special type of kitchen appliance.

In object-oriented computerese, the microwave in my kitchen is an instance of the class microwave. The class microwave is a subclass of the class oven, and the class oven is a subclass of the class kitchen appliances. We say that microwaves inherit their cooking properties from oven.

Humans classify. Everything about our world is ordered into taxonomies. We do this to reduce the number of things we have to remember. Take, for example, the first time you saw a hybrid car. The advertisement probably called the hybrid “unique, the likes of which have never been seen.” But you and I know that that just isn’t so. I like hybrids and I will grant you that they have a lot of differences under the hood, but hey, a hybrid is still a car. As such, it shares all of (or at least most of) the properties of other cars. It has a steering wheel, seats, a motor, brakes, and so on. I bet I could even drive one without first reading the owner’s manual.

I don’t have to clutter my limited storage with all the things that a hybrid has in common with other cars. All I have to remember is “a hybrid is a car that …” and tack on those few things that are unique to a hybrid (like the price tag). I can go further. Cars are a subclass of wheeled vehicles along with other members, such as trucks and pickups. Maybe wheeled vehicles are a subclass of vehicles, which includes boats and planes. And on and on and on.

Why Classify?

Why do we classify? It sounds like a lot of trouble. Besides, people have been using the functional approach for so long, why change now?

It may seem easier to design and build a microwave oven specifically for this one problem, rather than build a separate, more generic oven object. Suppose, for example, that I want to build a microwave to cook nachos and nachos only. I wouldn’t need to put a front panel on it, other than a Start button. I always cook nachos the same amount of time, so I could dispense with all that Defrost and Temp Cook nonsense. My nachos-only microwave needs to hold only one flat little plate. Three cubic feet of space would be wasted on nachos.

For that matter, I can dispense with the concept of “microwave oven” altogether. All I really need is the guts of the oven. Then, in the recipe, I put the instructions to make it work: “Put nachos in the box. Connect the red wire to the black wire. Bring the radar tube up to about 3,000 volts. Notice a slight hum. Try not to stand too close if you intend to have children.” Stuff like that.

But the functional approach has some problems:

· Too complex: I don’t want the details of oven building mixed into the details of nacho building. If I can’t define the objects and pull them out of the morass of details to deal with separately, I must deal with all the complexities of the problem at the same time.

· Not flexible: Someday I may need to replace the microwave oven with some other type of oven. I should be able to do so as long as its interface is the same. Without being clearly delineated and developed separately, it becomes impossible to cleanly remove an object type and replace it with another.

· Not reusable: Ovens are used to make lots of different dishes. I don’t want to create a new oven every time I encounter a new recipe. Having solved a problem once, it would be nice to be able to reuse the solution in future programs.

The remaining chapters in this part demonstrate how the object-oriented language features of C++ address these problems.

In real life, it isn't quite as pure as I make it sound here. I can't spend the time to build the software equivalent of a generic microwave oven. After all, teams of engineers spends thousands of developer hours designing microwave ovens (and still the front panel comes out incomprehensible!). When I build my classes, I generally only build in the capabilities that I will need for the particular problem at hand, but still the principle is the same. When I am building the microwave oven, I need only think about the oven. When I am making nachos, I only have to think about using the oven. It's simpler that way.