Chapter 13: Making Classes Work 169

Why bother with member functions?

Why should you bother with member functions? What’s wrong with the good ol’ days:

class Savings

{

public:

unsigned accountNumber; float balance;

};

float deposit(Savings& s, unsigned amount)

{

s.balance += amount; return s.balance;

}

Here, deposit() implements the “deposit into savings account” function. This functional solution relies on an outside function, deposit(), to imple­ ment an activity that savings accounts perform but that Savings lacks. This gets the job done, but it does so by breaking the object-oriented (OO) rules.

The microwave oven has internal components that it “knows” how to use to cook, defrost, and burn to a crisp. Class data members are similar to the parts of a microwave — the member functions of a class perform cook-like functions.

When I make nachos, I don’t have to start hooking up the internal compo­ nents of the oven in a certain way to make it work. Nor do I rely on some external device to reach into a mess of wiring for me. I want my classes to work the same way my microwave does (and, no, I don’t mean “not very well”). I want my classes to know how to manipulate their internals without outside intervention.

Member functions of Savings such as deposit() can be written as external functions. I can put all of the functions necessary to make a savings account work in one place. Microwave ovens can be made to work by soldering and cutting wires. I don’t want my classes or my microwave ovens to work that way. I want a Savings class that I can use in my banking program without considering how it might work on the inside.

Adding a Member Function

There are two aspects to adding a member function to a class: creating the member function and naming it (sounds silly, doesn’t it?).

170 Part III: Introduction to Classes

Creating a member function

To demonstrate member functions, start by defining a class Student. One possible representation of such a class follows (taken from the program CallMemberFunction):

class Student

{

public:

// add a completed course to the record float addCourse(int hours, float grade)

{

//calculate the sum of all courses times

//the average grade

float weightedGPA;

weightedGPA = semesterHours * gpa;

//now add in the new course semesterHours += hours; weightedGPA += grade * hours;

gpa = weightedGPA / semesterHours;

//return the new gpa

return gpa;

}

int semesterHours; float gpa;

};

The function addCourse(int, float) is called a member function of the class Student. In principle, it’s a property of the class like the data members semesterHours and gpa.

There isn’t a special name for functions or data that are not members of a class, but I’ll refer to them as non-members.

The member functions do not have to precede the data members as in this example. The members of a class can be listed in any order — I just prefer to put the functions first.

For historical reasons, member functions are also called methods. This term originated in one of the original object-oriented languages. The name made sense there, but it makes no sense in C++. Nevertheless, the term has gained popularity in OO circles because it’s easier to say than “member function.” (The fact that it sounds more impressive probably doesn’t hurt either.) So, if your friends start spouting off at a dinner party about “methods of the class,” just replace methods with member functions and reparse anything they say.