How to build objects from similar template classes

Question

My goal is as follows.

I am working with proteins in a data analysis setting. The data available for any given protein is variable. I want to be able to build a protein class from more simple parent classes. Each parent class will be specific to a data layer that I have available to me.

Different projects may have different layers of data available. I would like to write simple classes for the protein that contain all of the variables and methods related to a specific data layer. And then, for any given project, be able to compile a project specific protein class which inherits from the relevant data layer specific protein classes.

In addition, each data layer specific protein class requires a similarly data layer specific chain class, residue class and atom class. They are all building blocks. The atoms are used to build the residues which are used to build the chains which are used to build the protein. The protein class needs to have access to all of its atoms, residue and chains. Similarly the chains need access to the residue and atoms.

I have used vectors and maps to store pointers to the relevant objects. There are also the relevant get and set methods. In order to give EVERY version of the protein variables and getter and setter methods I have made 1 template class for the atom, residue, chain and protein. This template class contains the vectors and getter and setter methods which give the protein access to its chains, residues and atoms. This template class is then inherited by every data layer specific protein class.

Is this the best approach?

Answer 1

You might want to look at the Composite Design Pattern to organize your multi-level data and to the Visitor Design Pattern to write algorithms that "visit" your data structure.

The Composite Design Pattern creates a Component interface (abstract base class), that allows for iteration over all the elements in its sub-layer, adding/removing elements etc. It should also have an accept(some_function) method to allow outside algorithms be applied to itself. Each specific layer (atom, residue, chain) would then be a concrete class that derives from the Component interface. Don't let a layer derive from its sub-layer: inheritance should only reflect an "is-a" relationship, except in very special circumstances.

The Visitor Design Pattern creates a hierarchy of algorithms, that is independent of the precise structure of your data. This pattern works best if the class hierarchy of your data does not change in the foreseeable future. [NOTE: you can still have whatever molecule you want by filling the structure with your particular data, just don't change the number of layers in your structure].

No matter what you do, it's always recommended to only use inheritance for re-using or extending interface, and to use composition for re-using / extending data. E.g. the STL containers such as vector and map don't have virtual destructors and were not designed to be used as base classes.

Answer 2

First up, using inheritance is a nice way of abstraction and should help you build custom classes easily paving way for re-usability and maintenance.However spare a moment to consider your data structures.Using a vector seems like the most natural way to employ dynamic data, however, re-sizing vectors comes with some overheads, and sometimes when dealing with large data, this becomes an issue. To overcome this, try to come up with an average number of data that each would have normally have.So you can have an array and a vector, and you can use the vector only when you are done with the array.This way you don't run into overheads too often. Depending on the actual processing that you are about to do, you might want to re-think your data structures.If for example your data is sufficiently small and manageable, you can just use vectors and concentrate more on the actual computation.If however large data sets are to be handled, you might want to modify your data structures a little to make the processing easier.Good Luck.