| | With the traditional scoring hierarchy, classes like this one are created and accessed via the ScoringManager, which is itself a Singleton class. These "potential" classes are only created and initialized when the use of the EnergyMethod these classes correspond is encountered. No point in reading database files for a term if that term is not being used in some score function. However, the surface energy is used when users specify they want to use it on the command line - NOT via a score function. The score/energy is done within an interaction graph. One might ask why I just don't put the logic for reading in the database file to the interaction graph init methods. However, there will be cases where I will want to just score a protein (and not do any design) where I will want the database file to be read in. Scoring doesn't use interaction graphs, so if the code for that was located there, these values would not be read in. Instead, I've decided to implement this as its own separate class. It uses the Singleton design pattern so the database will only get read in once during a run. More...
|
