Discussion
Some of the drawbacks of existing class libraries and how they are avoided
in the STL are covered in the STL Tutorial and Reference Guide (Musser
and Saini, 1996). The difficulties mentioned in this book are incompatibility
of classes from different libraries, their relative inefficiency due to
the over use of inheritance and the problem of unwieldy interfaces. Discussed
below are some additional problems encountered during the development of
the prototype class library for bioinformatics and how they can be overcome
with a STL-like design. The problems discussed here may have contributed
to the current low levels of object-oriented code reuse within biocomputing.
Complexity
Molecular modelling and bioinformatics involve manipulating a large variety
of complex data types in many different ways. The more complex a class
library, the more effort is required to learn how to use it and the less
likely that it will be widely adopted. The coding efficiency of the students
using our prototype class library was significantly decreased by the need
to accustom themselves to parts of the library before using them. The STL
is simpler to use than a normal class library because there is great commonality
in the way components of the same category are used. It is likely that
the use of the STL will become very familiar to C++ programmers. This familiarity
will transfer to the BTL and make its use almost second nature to these
programmers.
Flexibility
Adding to the problem of keeping the library simple was the fact that the
intended users include researchers. This meant that the library had to
be extremely flexible. Flexibility can be achieved in OOD through the use
of abstract base classes and inheritance. However, these features impact
upon execution speed. In addition, the main method for adapting class libraries
is by adding leaves to the class trees which provides only limited flexibility.
Generic components within the STL can usually be used independently of
the rest of the library and new components can be added as and when they
are needed.
Subjectivity of Abstract Data Types
Perhaps the greatest problem of using the class library approach to increasing
software reuse in biocomputing is that users have to accept a more or less
fixed model of molecular entities. In reality, the conception of what something
like a molecule is and what you can do with it varies between individuals,
over time and with the task being performed. If the generic programming
approach is followed users can easily construct small class libraries tailor-made
to their needs using components from the STL, the BTL and similar libraries
such as the TNT.
Duplication of Functionality
If, for example, one would like to provide the a function CalcCentoid()
for a Molecule, a Residue and a Chain class then separate versions of the
code to perform this function would normally be put in each of these classes.
There are ways of avoiding such repetition but none are as effective as
having a generic CalcCentroid function. This method frees each class that
needs such functionality to store its atomic co-ordinates in any of a number
of different ways, while still calling the same piece of code to do the
calculation.