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.