Improvements/reconsidering the Adapter set-up and Modules mechanisms

[alelom]

Description:

As seen here: BHoM/ETABS_Toolkit#422 (review)

We had an unpredicted failure because of the following:

• we are constructing the functionality at runtime of a class (ETABS_Adapter) from within the class' constructor;
• this functionality depends on another service (modules) which itself depends on the correct configuration of the class (ETABS_Adapter's Id).
• The service module is not injectable via the ctor but is required to exist independently.

Because we had the incorrect ordering of instructions in the ctor (we declared the modules before the setting of the AdapterId), this raised a failure in the module loader, which required the AdapterId to be set.

Ideas

Possible solutions commonly adopted that require reworking the current architecture are:

• Dependency Injection: e.g. ctor injection via an IoC container
• Inheriting a base abstract adapter that exposes the functionality

Other solutions keeping current architecture are:

• adding the dependency on AdapterId on the modules
• making sure AdapterId is set before entering the ctor:
  • adding a static ctor
  • setting it as default value, never inside the non-static ctor