Input Layer



The input Layer is responsible for accessing data. It provides methods which encapsulate the in- and output processing and allow easy access to the data.
Since one challenge of our framework is to integrate various different data sources, a couple of different approaches for designing and implementing the input layer are possible:
One example would be the wrapper concept which provides a set of uniform methods to access the data. This means that for all possible data features specific methods have to be available. It is obvious for this approach to quickly arise the problem that a lot of functions must be implemented although no data may be available for a given feature. For example in a plain FASTA file no information about structural classes is stored. Another problem of the wrapper design is that the addition or deletion of new features results in the need to change all interfaces and classes which inherit from the superclass.
Another possible design pattern would be the Abstract Factory (Gamma, Helm et al. 1994) design as used by BioJava. Although this is a solid approach with a couple of advantages it can easily result in complicated object models because adding a new feature requires a couple of new classes and interfaces to be implemented. This would result in a very flexible but overloaded model and therefore design follows the first design principle:
The framework presented here is build upon a very slim basic input layer. The interface IInput is provided, which includes methods to access sequence and sequence identifiers. All input layers compatible with the framework must be descends of this interface. For illustration the access to a complex data source like a PEDANT database the sub-interface IPedant inherits from IInput and defines additional data-handling methods. Analogously other input sources are defined via sub-interfaces.
This modular-interface design pattern has a couple of advantages. In particular important is that new data sources can be easily added by providing a new interface, there is no need for refactoring existing interfaces. Therefore existing code is preserved which means that development investments are saved. Furthermore different interfaces and implementations can be provided by third-hand parties comfortably for example to import specific file formats.
This ensures a high flexibility and reliability for developers and users.
Additionally to the interfaces working implementations are provided which allow instant usage of the framework classes.