OOP style guide

design specification

A minimal article contains an abstract, introduction, body, conclusion and reference list.

Identify the most important classes of your application and their responsibilities, describe the evolution of your design, and the pros and cons of the current design (E.g. "The original implementation contained a single object controlling the entire application. We changed the design and distributed the functionality of the control object over the objects X, Y, and Z. The main reason for this was that the control object needed knowledge about every single class in our application, which was a maintenance nightmare. Additional advantages include ... However, the disadvantage is ..." or "We moved functionality from classes X, Y, and Z to a common base class. We defined this base class as an abstract base class (it has pure virtual member function f1 and f2) because ..." or "We used the MVC paradigm (or Document/View) to separate the GUI from the rest of the application", etc)

implementation

header files and class definitions (C++)

It is a good custom to create a header file for each class you define. Try to move as much implementation as possible from the header file into the separate corresponding implementation file.

Try to keep your header files as small as possible. Do not include other files in your header unless:

• The class has a base class. Include the file defining the base class.
• The class has a data member which is not a pointer or a build-in type. Include the file defining the class of the data member.
• The class has a function member which needs a parameter which is not a pointer or a build-in type (note: this may represent an error!). Include the file defining the class of the parameter.

Use forward declarations for all other class names used in the header, and include the corresponding class definitions in the implementation file. This style avoids "recursive include" errors and unnecessary re-compilation in combination with makedepend. Example:

   // file example.h:
   #ifndef	_EXAMPLE_H_
   #define	_EXAMPLE_H_
   
   #include <widgets/canvas.h>	// base class
   #include <list.h>		// data member
   
   class button;			// forward declarations
   class widget;			// ... included in example.cc
   
   class example: public canvas {
     public:
       example(widget* w, ...);
       virtual ~example();
       ...
     private:
       button* Cancel;
       list<int>	score;
   };
   
   #endif
  

constructors, destructors, operators and other member functions

• Virtual constructors do not exist in C++. Make sure you know in what case you'd like to have a ``virtual constructor'' and how to get the desired effect.
• Make all destructors virtual unless you really know what your doing.
• Be sure you know what Coplien's Orthodox Canonical Class Form is.
• Make sure you know how to use the ``const'' keyword.
• Try to avoid function names for which equivalent operator names are available. E.g. use counter::operator++() instead of counter::incr(), use mylist::operator==() instead of mylist::equals() etc.
• Do not repeat the class name in your member functions name (e.g. do not use list::sort_list())