When we wish to design modules that can be extended into different modules there are two basic areas we have to make sure are flexible and reusable:
- Manager class (API class)
- Views (UI)
As the diagram suggests, ideally, we would develop one View (called ReusableView). Given that it makes sense from the requirements standpoint, we would like to use that View in both Module1 and Module2 modules. Since we cannot know in advance where in module View hierarchy this View will be used, we should make the View hierarchy ambivalent - meaning that View can work at any level of the View hierarchy.
Somewhat connected to the hierarchy ambivalence is the host ambivalence. At the moment of the View design we do not know which View will serve as a Host for our Reusable View, therefore we should design the View in such a way that it does not matter which View is the Host.
Finally, we are not creating carbon copy modules, but rather modules that are very similar, yet different in certain details. Most probably, the template used by our reusable View will differ from module to module. In that aspect we also have to ensure that our View can work with different templates and different implementations of View child controls.
It is important to note that we will not be able to change absolutely everything (nor would it make sense - if we need to change everything - we may just as well create a new View). So for example, the crucial child controls that View is using to perform its function will have to be present in all templates. We will see, however, how we can take advantage of interfaces to loosen up these requirements.
In the following three articles we will explain and give code samples on how to achieve the goals we have set for the reusable View design:
- Host ambivalence
- Hierarchy ambivalence
- Child control ambivalence