Priorities:

Many design decisions are compromises but here is a list of our priorities in order:

1. Ease of use
2. Efficiency of execution
3. Extensibility
4. Modularity
5. Functionality

ANSI C++ Features:

We are making full use of some relatively new additions to C++ that are included within the draft ANSI standard definition of the language. The main one of these features is the Standard Template Library (STL). Virtually all the containers (data structures) that we use come directly from this library or are derived from containers in this library. We also use the bool type and the string type instead of char* types. Run-time Type Identification (RTTI) is not yet implemented properly in the compiler that we currently use for development (gcc version 2.7.2) so we use a custom built method for this. We plan to switch over to the standard method as soon as possible.

Garbage Collection:

As C++ does not automatically remove objects that are no longer accessible we make use of a template Handle class¹ where ever possible. Objects are referenced via this class and not via pointers directly. A reference count is kept for each non Handle object created using new and when the last Handle to that object is deleted, the object itself is deleted.

If the user is given full responsibility for garbage collection then run-time errors can easily arise which are very differcult to track down.

The Open-Closed Principle:

We intend to follow the open-closed principle^2,3 of object-orientated as closely as is practicable. This principle states that you should design modules that are "Closed for Modification", i.e. are never change, and are "Open For Extension", in that their behaviour can be augmented. Aspects of our Coding Conventions are designed to encourage contributors to stick to this principle.

An example of the application of this principle in our design is the Atom class. As an atom can be modelled in many different ways, this class only contains the bare minimum of data members, for example, those representing its position as the coordinates of a single point in space. These data members should not change over the development of the library, thus the Atom class can be "Closed for Modification". This class is "Open For Extension", for example, the classes Carbon, Hydrogen, Oxygen etc. are derived from Atom. These derived classes contain data members specific to the atoms of the element they represent, for example their atomic weight. Another way to represent a carbon atom would be to have one or more fields within the Atom class for element, atomic weight etc.. However, using this method, the Atom class would have to be changed to add a new element and thus cannot be "Closed for Modification".

In general, creating derived classes, rather than having descriptive fields within a generic class, although leading to a proliferation of small classes, makes code easier write and understand. For example, to create an alanine side chain one would create, a Carbon object, and three Hydrogen objects instead of four Atom objects with element="carbon" or element="hydrogen".

(1) Stroustrup, B., "The C++ Programming Language (2nd Ed.)", Addison Wesley, 1991
(2) Meyer, B. "Object Orientated Software Construction", Prentice Hall, 1988, p23
(3) Martin, R.C., "The Open-Closed Principle", C++ Report, ???, p37

Any questions and bug reports to Mark Williams. This page was last updated on the 25th of May 1999.