The logical structure of protein objects permits one to access a protein on a residue-by-residue or on an atom-by-atom basis, and to switch back and forth. Ultimately, Ezprot is intended to integrate the analysis of protein structure and sequence.

We have already described the function read_pdb_file() that takes a filename as argument, reads the named PDB file and stores its' data in a protein object. This function is quite robust; it reads almost everything in a PDB file--residue types, atomic coordinates, heteroatoms, metal ions, and even multiple sidechain conformations. There is also a function fprint_pdb() that writes a protein to standard output in PDB format. In combination, these functions make it easy to read a protein structure, process it, and output an altered structure.

read_pdb_file() can read different parts of PDB files. By default, it will read the PDB file header, the sequence and the atomic data. But you can control what parts of the PDB file are read by passing in an extra argument, a bitmask. The bitmasks that can be passed are defined as macros in the file protein.h. For example, protein.h defines a bitmask, ProtIO_secstruc_Mask, which will make the function read the secondary structure records in PDB files (and read the sequence, but ignore the atomic data). Below we read the file for lysozyme and print the names and sequence numbers of all residues in alpha helices as identified by the file.

#include "protein.h"  /* Header file declares bitmasks */
protein  prot;
/* POINTERS to amino acids and a.a. chains */
aa_chain   *aac;
amino_acid *aa;
 
/* Read lysozyme's sequence and secondary structure. */
prot.read_pdb_file("PDB6LYZ.ENT", ProtIO_secstruc_Mask);
 
for (aac = prot.first(); prot.not_at_end(aac); 
     aac = prot.next(aac))
  {
    printf("Helix residues in chain %c:\n", aac->name());
 
    for (aa = aac->first(); aac->not_at_end(aa); 
         aa = aac->next(aa))
 
      if (aa->in_helix())  /* Is this residue in helix? */
        printf("%s %d\n", aa->name(), aa->seq_num());
  }

(7)

Function in_helix() tells if a residue is in a helix. As another example, protein.h defines a bitmask, ProtIO_header_Mask, which will make the function read just the header in PDB files. Next, the bitmasks can be combined with bitwise operators to make compound commands. For instance, to make read_pdb_file() read both the header information and the secondary structure records, we could combine two bitmasks with the bitwise OR operator "|":

prot.read_pdb_file("PDB6LYZ.ENT", 
                   ProtIO_header_Mask | ProtIO_secstruc_Mask);

The output from function fprint_pdb() can be controlled in the same way.

As an example of sophisticated functions that can be performed elegantly with Ezprot, we discuss how to perform oligomer transformations on a protein object. Nearly half of all structures in Protein Data Bank files require some transformation to give them the same form as the protein in vivo. Often, for a protein that is a dimer in vivo, the file will give the coordinates of just one chain, so a duplicate chain should be created, rotated and displaced. Even more often, multiple copies of a monomer will appear in the crystal asymmetric unit, and one or more chains should be deleted to make the monomer. Missing or incorrect oligomer interfaces can introduce errors into some kinds of analyses.

The quaternary structure of a protein in vivo is sometimes mentioned in the comment section of PDB file headers, but this is in a non-standardized format, and anyway many files lack any mention of the true quaternary structure. We have therefore introduced the following convention: for each PDB file, the transformation necessary to make the in vivo structure is stored in an auxiliary file with a standard format, called an Oligomer-Generating Matrix (OGM) file. For example, the PDB file for enolase is called PDB7ENL.ENT and contains one chain, but enolase is a dimer. The OGM file for enolase is called 7ENL.OGM and contains one rotation matrix and a displacement vector, and looks like this:

# This is the OGM file 7enl.ogm (ENOLASE).
    0.0  -1.0   0.0      124.1
   -1.0   0.0   0.0      124.1
    0.0   0.0  -1.0       66.9
 

Next, superoxide dismutase is a dimer in vivo, but the file PDB2SOD.ENT contains four chains. The file 2SOD.OGM will delete two chains:

# This is the OGM file 2sod.ogm (SUPEROXIDE DISMUTASE)
# This means "Delete chains B and G"
~B
~G

Such files must unfortunately be created by hand, but the Ezprot library includes more than 100 OGM files for popular proteins. We find this configuration to be especially convenient when analyzing a large database of many proteins.

An oligomer transformation is clearly a complicated thing, involving one or more matrices, displacement vectors, or instructions on chain deletion. There are many good reasons why, inside the program, it is better to represent an oligomer transformation as a class, rather than as a set of complicated arrays passed as arguments to functions. The Ezprot library defines a class called olig_transfrm whose purpose is to read OGM files, store the data and transform protein objects. By defining a transformation as an object, we can also keep a transformation around and use it later on other objects besides proteins. The code fragment below will read a PDB file, read the corresponding OGM file, transform the protein, and output the transformed protein in PDB format.

/* GENERATE OLIGOMER FOR SUPEROXIDE DISMUTASE, 
   OUTPUT OLIGOMER IN PDB FORMAT.  */
 
#include "protein.h"         /* Declares protein */
#include "olig_transfrm.h"   /* Declares olig_transfrm */
 
protein       prot;    /* protein object */
olig_transfrm ogm;     /* oligomer transform object */
 
/* Read PDB file for superoxide dismutase: */
prot.read_pdb_file( "PDB2SOD.ENT");
 
/* Read OGM file for superoxide dismutase: */
ogm.read_ogm_file( "2sod.ogm");
 
/* TRANSFORM TO FULL OLIGOMER */
prot.transform( ogm);
 
/* Output full oligomer in PDB format to standard out */
prot.fprint_pdb();

(8)

The function fprint_pdb() writes the protein object to standard output in normal PDB format. Notice that the function prot.transform(ogm) may involve the creation or deletion of chains. Memory for chains is allocated and deallocated automatically by Ezprot. The equivalent transformation functions in a non-OOP application would require more than a dozen arguments with appropriate array dimensioning, and would still not be as flexible as Ezprot functions.

Most Ezprot functions can be customized to analyze parts of a protein, rather than the whole molecule. As an example, we first calculate the total accessible surface area of an object prot, assuming it has already been initialized:

float prot_area;
prot_area = total_surface_area( prot, "accessible");

(9)

Other Ezprot functions would return the individual areas of all atoms stored in an array, but function total_surface_area() by default returns the whole surface area of the protein. However, total_surface_area() can selectively exclude atoms from analysis if the atoms are "hidden". Classes like protein, aa_chain, amino_acid, etc., have a function hide() that marks their constituent atoms as hidden. The effect is reversed by the function show().

In the code fragment below, we calculate the area of the tripeptide from residue number 37 to 39 of the first chain of lysozyme--just the tripeptide in isolation, as if the rest of the protein structure did not exist:

 
#include "protein.h"    /* Declares protein class */
#include "ezp_area.h"   /* Declares area functions */
 
protein prot("PDB6LYZ.ENT"); /* Initialize & read file*/
float   tripep_area;
 
prot.hide();              /* Hide all atoms */
prot[0]( 37, 3).show();  /* Show atoms in tripeptide */
 
tripep_area = total_surface_area( prot, "accessible");

(10)

We used a different syntax for declaring the protein, in which the object is initialized and the PDB file is read in a single step. All atoms in prot are then hidden. Operator [0] applied to the protein returns the first (zeroth) chain, then the parentheses operator (37,3) extracts from that chain a substring consisting of the three residues from 37 to 39. Their atoms are shown while all other atoms remain hidden. Thus, function total_surface_area() returns the area of the tripeptide structure in isolation.

Ezprot functions can be customized to analyze any subpart of a protein, but this additional flexibility is achieved without adding extra arguments to function calls.

The Ezprot library includes a number of small programs that perform common tasks. Examples are generating full oligomers from PDB file structures, deleting hydrogen atoms or heteroatoms, identifying oligomeric interfaces or the structural epitope of a substrate, calculating interface areas, etc.

By default, these programs read from standard input and write to standard output, often in PDB format. In an operating system like UNIX, the output of one utility can be piped into another utility with "|". Here we generate the in vivo oligomeric structure for superoxide dismutase, strip off heteroatoms and hydrogen atoms, and calculate the area buried at the oligomeric interface:

gen_olig -pdb pdb2sod.ent -ogm 2sod.ogm | striphets  \
   | stripatoms -elem "H" | oligburial

The utilities are bundled with Ezprot. The source code is provided to serve as simple examples for those learning to write programs with the library.

The library includes many functions not mentioned in this paper. But the current version (v.1.0) also lacks many functions that might be needed, such as routines for indentifying hydrogen bonds. We have established a site on the World Wide Web for distributing the library. Moreover, through this Web site other researchers can make suggestions as to which routines are most needed by Ezprot, and can contribute source code. We can translate submitted code to C++, or write original routines, and incorporate the new code into future versions of the library. This can be done while maintaining compatibility with previous versions. However, we emphasize that the essential infrastructure is already in place for creative research that integrates the analysis of sequence and structure.

Ezprot classes and functions are very elegant and intuitive, but the benefits of elegance are more than aesthetic. Elegant functions are more immune to bugs. Non-OOP function calls often consist of long strings of arguments. As non-OOP programs become larger and more complicated, arguments lists get longer; and in FORTRAN, common blocks likewise tend to grow. This makes it easy to switch two variables or to dimension an array incorrectly. Beyond a certain point, large non-OOP applications become unmanageable, which is why commercial operating systems use OOP. In our experience with Ezprot, large and complex applications are much more resistant to bugs.

Programs using Ezprot are highly readable. With clutter out of the way, one can read another person's code and immediately recognize the thinking behind his or her algorithm. Thus, Ezprot can facilitate the exchange of software between molecular biologists.

The object-oriented basis of Ezprot also has disadvantages that may make the library inappropriate for some purposes. Ezprot represents atoms by the coordinates of their centers and their Van der Waals radii. The library has no representation for electron density, and thus it would be of limited value to crystallographers trying to solve structures (in principle it could be used for model building.) We have carefully designed the library for optimum performance, with in-line functions and other tricks; however, some older C++ compilers have a reputation for producing slow executables. Ezprot would therefore be inappropriate for very computationally intensive tasks, like molecular dynamics. (For our research we have found Ezprot's performance to be reasonable. It's easy to write small test programs in Ezprot to compare the performance on your system.)

We expect Ezprot to be most useful for protein analysis objectives such as protein fold prediction, sequence alignment, surface area calculation, molecular docking and rational drug design, and similar tasks. Ezprot is a flexible platform from which a variety of algorithms can be built.

To sum up, the virtues of Ezprot are that it is intuitive and easy to learn, it is flexible and powerful, it enhances immunity to bugs, it guarantees compatibility with future updates of the library, and it facilitates the exchange of source code between researchers. The library can serve as a standard platform for the rapid development of new algorithms for analysis of protein sequence and structure. Ezprot is built to grow.

As explained above, a class is a data type defined by the library, and an object is a specific example (instance) of a class. The difference between an object and an ordinary FORTRAN record is this: a programmer can directly access the data fields in a record; but the programmer who uses a class cannot access its' fields directly. Instead, for each class there is a set of functions called "member functions," which come with the library, and which are the only functions allowed to directly access that class' internal fields. Only the protein class' member functions can access the protein class' fields; only the amino_acid class' member functions can access the amino_acid class' fields, etc. Non-member routines have to use member functions to get at the class' data.

The library includes all member functions that the classes need. Most member functions are very simple, but for more advanced tasks they can be complicated. Programmers using the library write normal (non-member) routines that can manipulate objects, call member functions, and build more complicated algorithms from these elements.

In C++, regular function calls look like function calls in C. Member functions, however, are applied to an object with the operators "." or "->", which are the same as the operators used in C to access the fields of a struct. In code fragment (1), the function read_pdb_file() is a member function of class protein. The member function is applied to object prot1, and it can directly store or retrieve data in prot1's fields. The program that uses the class, however, cannot store data in the fields directly.

This rule may appear excessively strict. The motivation for the rule is that, when a class or library is improved, the way the data is represented usually changes, with new data types or different fields. If every function in every program that uses a class were permitted to access its' fields, then, when the fields are improved, every program dependent on the fields would need to be rewritten. On the other hand, consider programs that only access fields indirectly by calling member functions. When the class is improved and the internal representation of the data changes, only the member functions of that class must be rewritten by the library designers. Old programs that used the library do not need to be rewritten, because they call member functions, which add an extra layer of protection.

As an example, consider the Year 2000 problem caused by the huge number of programs that represented dates as a set of data fields. When the data needs to be represented in a new way--when a year must be represented as four digits instead of two--all programs dependent on a two-digit year field must be rewritten. But if instead dates had been coded as objects, only the date class' member functions would need rewriting, while the programs using the date class would still be compatible with a new library. Such a problem could be reliably fixed in half an hour instead of half a decade.

Sometimes a data structure is better off as an ordinary struct or record, while many times data is better off designed as a class. Even if a programmer does not have a religious devotion to the orthodoxy of OOP, a pragmatic attitude toward object-oriented programming may still lead to large benefits. In practice, programs using OOP are subjected to many small, gradual improvements which have a large cumulative effect. Non-OOP programs are subject to inertia: there is a general resistance to making improvements to routines even when they are needed, because improvements necessitate rewriting all dependent programs.

One might wonder if so many function calls in OOP imply a loss of efficiency. If a member function is very simple and short, the designers of a library can improve performance by declaring the function to be "in-line". Put very simply, such functions are like macros in C. The compiler will expand calls to the functions in-line, thus avoiding the overhead of regular function calls. Generally, the designers of a class have the responsibility of optimizing performance by declaring simple functions to be in-line, while the users of the class write and invoke functions in the normal way.

In OOP, member functions can be re-used in multiple classes. This makes it easier for the library designers, who can re-use the same code; and this also makes it easier for people using the library, who have fewer functions to learn about. The most common relationship between classes is called "class derivation" [10]. Member functions and data of one class, called the "base class", are implicitly also member functions and data in any classes derived from it, the "derived classes". An example is illustrated in Fig. 2. The amino_acid class and the hetgroup class (which represents compounds of heteroatoms) are siblings. Both have a function seq_num() that returns their sequence number within a chain. They share some functions because both classes are derived from the same base class, called compound. amino_acid and hetgroup picked up function seq_num() from the class compound. In addition to the inherited functions, each derived class can also add new functions of its' own. So the amino_acid class adds functions, like in_helix(), which tells whether the residue is in a helix. Likewise, class hetgroup adds a function, is_water(), which indicates whether a hetgroup is a water molecule. Large OOP applications are built by adding new functions layer by layer onto derived classes.

These details about class derivation are important for the programmer who writes the class library, but they are not very important for the programmer who uses the library. For the user of Ezprot, the main point is that there is a high degree of function standardization. Often, the same functions are used by different classes, thus making them easier to remember without consulting the documentation.