Interfaces and Implementations

However you write a stack class, the interface of a stack is defined by the operations push(), pop(), and depth(). These methods define the interface, and the actual code and data is called the implementation. It is very useful to separate these two different aspects of a class. A separate interface is easier to understand, and the implementation can be separately compiled.

Creating a Header File

To support separate compilation and to break a program into self-contained units, C++ encourages the use of header files. In the case of a function, a header file would contain prototypes, which would then be fully defined in another file. The equivalent for a class is similar. Within the class body are the member declarations, for both the data and the functions. Any client code that wants to use the Stack class only needs to include this header file:

// stack.h
#include <list>
class Stack {
private:
   std::list<int> m_list;
public:
   void push(int i);
   int pop ();
   int depth() const;
   bool empty() const;
};

This header file defines the interface to the class, and the implementation of the class is then defined elsewhere. The user of this class might not have the source code for the implementation; although having the source code can be useful, it is not essential. All the crucial information is present in the class definition and comments.

You should now be able to see how useful it is to label methods as const. When you do, the user does not have to refer to the implementation to know that Stack::depth() does not change the object. Note that the interface does not completely hide the details of the implementation; the user can make a pretty good guess that the stack uses a list. As previously discussed in Chapter 4, “Programs and Libraries,” in the section “The std Namespace,” you make it explicit that you are using the standard list, rather than just taking namespace std for granted.

The Implementation File

The implementation file for Stack looks like this, with the scope operator (::) used to show that the functions are members of the Stack class:

// stack.cpp
#include "stack.h"
 void Stack::push(int i)
 {
    m_list.push_back(i);
 }
 int Stack::pop ()
 {
     int val = m_list.back();
     m_list.pop_back();
     return val;
 }
 int Stack::depth() const
 {
     return m_list.size();
 }
 bool Stack::empty() const
 {
     return depth()==0;
 }

Note that you must have previously declared these methods in stack.h before you can define them like this; otherwise, the compiler complains that the method is not a member of the class. (Incidentally, you can define the members of a namespace in exactly the same fashion, and it is, in fact, the recommended way.) Must all methods of a class be separately defined like this? Simple set and get methods can be left in the header file, where they will are automatically inlined, as discussed in the section “struct and class.”

Separating the Interface from the Implementation

Separating the interface from the implementation of a class allows you to organize a program into well-defined modules. Practically, it is useful because it means that rebuilding a million-line program does not require compiling a million lines of code; usually only the implementation of a class changes, not the interface. You should not have to recompile a whole program just because of a small change in one method of Stack. This is the advantage of keeping even simple get/set methods out of the interface.

From an organizational point of view, separating the interface from the implementation means that responsibilities are kept separate as well. For example, you can think of the iostream library as the packaging and logistics department of a C++ program; it is concerned with how to physically get output out onto the screen, or into a file, or whatever. The client code merely has to ask.

Also, a programmer should not be swamped with details. Keeping the implementation separate is often called information hiding and goes hand-in-hand with encapsulation.