C++ BLAST Options Design

Design goals

• Isolate C++ toolkit users from details of CORE BLAST
• Allow easy setting of default options for common tasks for which BLAST is used
• Expose in an interface only those options that are relevant to the task at hand
• Provide a means of validating BLAST options
• Allow 'power' users to have unrestricted access to all BLAST options
• Design should be flexible to accomodate introduction/removal of options

Components

• CBlastOptionsFactory: This class offers a single static method to create CBlastOptionsHandle subclasses so that options that are applicable to all variants of BLAST can be inspected or modified. The actual type of the CBlastOptionsHandle returned by Create is determined by its EProgram argument. The return value of this function is guaranteed to have reasonable defaults set for the selected task.

• CBlastOptionsHandle hierarchy: The intent of this class is to encapsulate options that are common to all variants of BLAST, from which more specific tasks can inherit the common options. The subclasses of CBlastOptionsHandle should present an interface that is more specific, i.e.: only contain options relevant to the task at hand, although it might not be an exhaustive interface for all options available for the task. Please note that the initialization of this class' data members follows the template method design pattern, and this should be followed by subclasses also.

• CBlastOptions: This class contains all available BLAST options and it is provided to satisfy the design goal of allowing qualified users unrestricted access to all BLAST options. Because of this, it is very easy to set incorrect options, and hence it should be use sparingly. The use of its Validate method is strongly recommended.

Known deficiencies

The current design in noticeably weak in fulfilling the last design goal, in that it uses an inheritance hierarchy of CBlastOptionsHandle classes to provide specific interfaces for tasks, but this approach is breaks when an option is applicable to a parent class and not its child.

Furthermore, the EProgram enumeration is misnamed, as it should convey the notion of a task, similar to those exposed in the BLAST web page.

Future plans

A redesign of the C++ BLAST options API might be available in the future to overcome the deficiencies of the current APIs. Additional design goals include:

• Consistent local/remote behavior
• Provide distinction between algorithm options and application options
• Provide well defined guarantees about the validity of BLAST options
• Easy to use correctly, difficult to use incorrectly

Author:

Christiam Camacho <camacho@ncbi.nlm.nih.gov>

---