Feature #1290: === Core: framework ===
Review and possibly refactor IFormFactor class hierarchy
|Status:||Archived||Start date:||23 Aug 2016|
It seems that conceptually all concrete IFormFactor classes (with the exception of the two DWBA form factors) could be directly derived from IFormFactorBorn. Investigate this possibility and refactor accordingly. This is related to an issue with FormFactorCrystal, which now
#1 Updated by herck over 3 years ago
Currently, IFormFactorBorn does not only represent form factors that only depend on the wavevector transfer q, but there also exists a distinction in the treatment of polarized/non-polarized evaluation. To make IFormFactorBorn truly represent all from factors that only depend on q, an extra virtual evaluate_for_q_pol(...) would be needed (which can be given a default implementation that returns the scalar value times the unit matrix). Because of the dependency of the scattering density of a material on the wavelength, FormFactorDecoratorMaterial cannot be moved under IFormFactorBorn for now. This then recursively applies to all decorators, to FormFactorCrystal and FormFactorWeighted.