Programming to Interfaces not Implementations

What is an implementation?

An implementation is a specific approach to fulfilling the desired operations on a given page.

What is an interface?

An interface is an abstraction of specific operations into higher-level meta-operations; abstractions provide activities and properties that are common not only to a specific page format but to a whole set of similar pages.

How does PRPC make interfaces possible?

1. Polymorphism




Abstract class definitions can have activities defined without steps but with parameters defined. These activities are the interface.


A subclass can have the same activity defined but with specific steps that actually do something. These activities are the implementations.


An application that uses the class can define a property as being one of the abstract parent class and use Call method to invoke one of the interface activities on the property.


The Page-Change-Class or Page-New can be used to create a page structure that reflects a specific subclass of the defined abstract parent class.


At run-time, the specific version of the Activity in the subclass is fired even though the validation occurred against the abstract version.




2. RuleSet Prerequisites and Run-time RuleSet Lists




PRPC allows the creation of two different RuleSets that can contain identical activity definitions.


One is created as xxxBase has activities with empty steps. This RuleSet forms the Interface.


Another is created as xxxImpl has the same activities with actual steps defined. This RuleSet forms the Implementation.


The RuleSet version of the calling application is has the xxxBase RuleSet added to its prerequisites.


Activities are called from within the application and validate against the versions in the xxxBase RuleSet.


The xxxImpl RuleSet is placed above the xxxBase RuleSet in the Application records list of associated RuleSets.


At run-time, the specific version of the Activity in the xxxImpl RuleSet is fired even though the validation occurred against the abstract version from the xxxBase version.

KROME modules make heavy use of the latter approach to allow the possibility of changing system behavior through deployment action and security tweaks rather than through programming.