TPC API - Restructuralization part 2: create tpc directory structure to reflect Design by Contract paradigm
necessary 1st step to have API for tpc detector in the future.
example of how it must look at the end:
- /detectors/tpc/ directory should contain only Abstract and Base Classes encapsulated in library libtpc
example /detectors/tpc/AbstractTpcClusterHitFinder.h (.cxx) - implementations of these classes should be structured in their own subdirectories on a lower level of hierarchy
example /detectors/tpc/clusterHitFinder/fast/TpcClusterHitFinderFast.h (.cxx)
/detectors/tpc/clusterHitFinder/mlem/TpcClusterHitFinderMlem.h (.cxx)
these are encapsulated on a level /detectors/tpc/clusterHitFinder/ into libtpcClusterHitFinder library.
This way libtpc is an API to TPC detector, while libtpcClusterHitFinder is library of implementations of clusterHitFinder algorithm.
The API is subject to tests (Acceptance TDD), which are in fact module performance requirements translated into computer language.
For example such a test for clusterHitFinder module can be precision of Hit finding in a cluster.
In this way API and TDD are separated from implementations.
Example: every new implementation of clusterHitFinder (say using neural networks) algorithm is added into libtpcClusterHitFinder library. It must implement API class (AbstractTpcClusterHitFinder) and its performance is tested through API by tests. These tests can test requirements on any clusterHitFinder algorithm implementing AbstractTpcClusterHitFinder.
This way the main focus of development shifts to fulfilling the requirements - management of API and tests (API implementations fulfilling the requirements).