There is a well-known guiding principle that when one builds a new software: That the software should be open for enhancement, but closed for modification.
Let us assume that existing FS-PM groupware functionality, needs to be enhanced with more functionalities like Master Policy (MP). Hypothetically for the sake of this article, the following could be the functionality to be developed:
Now the above object(s) would have the same structure of the existing Master Policy. The question is how would one develop the above objects without much disruption? This blog attempts at answering this question.
For the sake of simplicity let us assume that the Master Policy has just a root node with no children. Its design will broadly look like the following diagram (UI, process layer is skipped for the sake of simplicity). Each of the boxes indicate MP Root Entity. And the BOL, BOC and DAA are layers as per PBT framework. The direction of control access is from top to bottom.
How could one adopt the existing above design to include new object MPT? The following figure highlights the same:
Basically, one has to create specialization at each layer (API, BOL, BOC, and DAA) and for the object (MPT). This design can be realized provided the classes are not marked final.
Here, one uses polymorphism by inheritance, the runtime instance of an object could be MPT or MP. This runtime polymorphism can be achieved using a façade class, provided the UI and process layer accesses the objects only through this façade class. But during the design time, the type of an object always refers to MP rather than say, MPT.
The advantage here is that in UI layer, even though MP object is referred, at runtime it could be any specialized object depending on the requirement. Hence, this approach leads us to less disruption.
Let us assume that existing FS-PM groupware functionality, needs to be enhanced with more functionalities like Master Policy (MP). Hypothetically for the sake of this article, the following could be the functionality to be developed:
- Master Policy Template (MPT): This is like a “Sample Application” for Master Policy. That is, one could create template for MP filled with header, creditor, beneficiary, commission etc. And then create MP wrt MPT. As a result, this creates MP filled with values from MPT. A customer could define each template for fleet, health, life insurance etc. This reduces the end user’s effort to create MP.
Now the above object(s) would have the same structure of the existing Master Policy. The question is how would one develop the above objects without much disruption? This blog attempts at answering this question.
For the sake of simplicity let us assume that the Master Policy has just a root node with no children. Its design will broadly look like the following diagram (UI, process layer is skipped for the sake of simplicity). Each of the boxes indicate MP Root Entity. And the BOL, BOC and DAA are layers as per PBT framework. The direction of control access is from top to bottom.
How could one adopt the existing above design to include new object MPT? The following figure highlights the same:
Basically, one has to create specialization at each layer (API, BOL, BOC, and DAA) and for the object (MPT). This design can be realized provided the classes are not marked final.
Here, one uses polymorphism by inheritance, the runtime instance of an object could be MPT or MP. This runtime polymorphism can be achieved using a façade class, provided the UI and process layer accesses the objects only through this façade class. But during the design time, the type of an object always refers to MP rather than say, MPT.
The advantage here is that in UI layer, even though MP object is referred, at runtime it could be any specialized object depending on the requirement. Hence, this approach leads us to less disruption.
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
