Specifications and Implementation

• Building Large Software Systems is a complex undertaking. No one person can understand every single line of code in a systems consists of thousands or even millions of lines of code. The only way to manage this complexity is by abstracting out the essential features of the system that effect the task at hand.
• Specifications tell the user what the software will do but not how it does it (the how is the software implementation).
• At the programming level, specifications are given as function prototypesi and class declarations (which contain among other things the function prototypes of the class functions)
• Normally these program level specifications are kept in header files (which by convention end in ".h")
• Seperating program specifications from program implementation also supports separate compilation which as several advantages:
  • Break Big Program into Manageable Pieces
  • Separate Specification (WHAT) from Implementation (HOW)
  • If the specification is unchanged, allows the implementation to change without effecting programs that use that implementation.
    The assignment on Sorting exploits this property - most sorting algorithms could use the same specification.
  • Hide Proprietary Software (only export libraries of compiled object code)
  • Speed the Compilation Process

• Example of generating a specification for the Coordinate example is given here.
• The Time class is descibed in section 6.7 of the book.
  • The header file is given here.
  • The implementation file is given here.

// Let's modify the simple example from fig 6.4 to demonstrate
// specification and implementation for a class
class Count {
public:
   int x;
   void print( ); // we only give the function prototype for "print" - not its definition
};

// ... later on - perhaps in a different file we define "print"
Count::print( ) { // notice the use of the scope resolution operator "::"
cout << x << endl:
}

• When defining a class's function separately, you need to tell the compiler which class the function belongs to.
• This is necessary since it is possible for different classes to use the same function name. We don't want the compiler to be confused.

ClassName :: memberName

• Although it may seem like a lot a extra work for little gain, get into the practice of dividing your classes into separate specifications and implementaion files.
• Much of the support system for C++ is built on separate compilation. Almost every C++ program uses some library functions and includes the library's specifications as a header file (e.g. iostream.h).
• There are some potential problems with the use of header files which can lead to "multiple definition" compiler errors.
  These can be eliminated by certain precautions explained in the book in section 6.7
  These involve the use of "#ifndef ...#define .. #endif" precompiler derectives.
• Separate compilation is usually managed by a Makefile (more to come on this subject later).