An idea for refactoring of Adoption

[denised]

The current implementation of adoptions is spread across the individual adoption classes, Helper Tables, the extractor, the code the extractor generates, and the customizations that get made in individual solutions. It is a very complex framework. It could be simplified:

• Instead of scenarios having separate ad/ca_pds/scurve etc., slots, have just _base_ref_adoption and _base_pds_adoption. These are _ slots because they are "base" adoptions, not the final calculated adoption (what HT outputs).
• Make a common base class for the different adoption types that can respond to the request for the adoption data as a DF. Make each adoption type inherit from it and implement that method.
  • Add an official Linear adoption class
  • Split S-Curve into two classes (perhaps one that inherits from the other)
  • Move the "single source" logic inside of the AD adoption, which is the only adoption that cares about this.
• Possibly, make the ability to react to a tam/tla limit part of what these classes do internally (one could imagine in the future S-Curve might gracefully approach the new limit, for example).
• Helper Tables doesn't need to be an object; it is just some code that is part of the adoption initialization in the Scenario object, which handles cross-influence between the fields, which will create the "real" adoption fields ref_adoption and pds_adoption.
• By performing the initialization code explicitly, the bi-directional recursion in HT will be eliminated. Also the construction of a bunch of variables just to pass to HT which may or may not need them will also be eliminated. There will be a single place that needs to branch on ac.pds/ref_adoption_basis, instead of several.
• As with the rest of initialization, quirks parameters may still be needed, and they can be set as config/override fields by the solution, and then used in the adoption initialization, as the other overrides are.