Inheritance example in Data Model design
I want to take exception to the example being used to explain polymorphism. We need to get beyond "Hello World" and travel to the "Real World". This is CLSA 7.x training.
We want to create reusable data models. We also want to create reusable business logic.
Pattern inheritance is OPTIONAL. Nevermind mind its Pega Best Practice, lets not forget that.
Data should be for representing STATE, NOT BEHAVIOR. In the "Hello World", Shape::Draw(), Rectangle:Draw() works for explaining the concept. If one is programming in language such as DotNet / Java it is less of an issue. When developers out of college see example provided in this Pega lesson, they are forever corrupted.
Ins-Quote-Data-Vehicle and Ins-Quote-Data-Vehicle-Car
Pattern inheritance is fine when we are using it to inherit Work-. That's a manifestation of the ECS recommendations from PEGA where business logic can be customized across differet levels of an organization (i.e. Divisions). If one wants to define Data Models that can be appropriately extended and built upon AND shared across the organization, then one should not define 'Vehicle' in a particular division that manages Insurance Quotes only. It prevents other divisions who need 'Vehicle' from inheriting it since they are in another branch of the ECS and 'Vehicle' is not visible.
For Data, DIRECT INHERITANCE should be used, as in
XXX-YYY-Data-Vehicle
XXX-YYY-Data-Car, XXX-ZZZ-Data-Truck
I want to take exception to the example being used to explain polymorphism. We need to get beyond "Hello World" and travel to the "Real World". This is CLSA 7.x training.
We want to create reusable data models. We also want to create reusable business logic.
Pattern inheritance is OPTIONAL. Nevermind mind its Pega Best Practice, lets not forget that.
Data should be for representing STATE, NOT BEHAVIOR. In the "Hello World", Shape::Draw(), Rectangle:Draw() works for explaining the concept. If one is programming in language such as DotNet / Java it is less of an issue. When developers out of college see example provided in this Pega lesson, they are forever corrupted.
Ins-Quote-Data-Vehicle and Ins-Quote-Data-Vehicle-Car
Pattern inheritance is fine when we are using it to inherit Work-. That's a manifestation of the ECS recommendations from PEGA where business logic can be customized across differet levels of an organization (i.e. Divisions). If one wants to define Data Models that can be appropriately extended and built upon AND shared across the organization, then one should not define 'Vehicle' in a particular division that manages Insurance Quotes only. It prevents other divisions who need 'Vehicle' from inheriting it since they are in another branch of the ECS and 'Vehicle' is not visible.
For Data, DIRECT INHERITANCE should be used, as in
XXX-YYY-Data-Vehicle
XXX-YYY-Data-Car, XXX-ZZZ-Data-Truck
Both 'Car' and 'Truck' in above example can inherit DIRECTly from 'Vehicle'. Ideally/possibly 'Vehicle' and even 'Car', 'Truck', etc. might be in SomeFramework-Data- layer. Regardless, 'Car', 'Truck', etc. should not pattern inherit from 'Vehicle'. Pattern inheritance for Data feels so wrong in so many ways.
***Updated by moderator: Lochan to move the post from Pega Product Support community***
Pegasystems Inc.
IN
Interesting discussion! Could somebody add little illustration and use-case(s) for using particular inheritance (pattern or direct) in Data Model Design.
Updated: 8 Sep 2016 10:43 EDT
Ai4Process
GB
Hi,
I agree with you that pattern is not as much important for Data- classes as it is for Work-classes.
Using pattern inheritance for Work- makes sense when you want to have containers
Org-App-Work-AutoLoan
Org-App-Work-House
Org-App-Work-House-Mortgage
Org-App-Work-House-HomeEquityLoan
In here, it makes sense to have "House" in order to contains rules that can be shared by "Mortgage" and "HEL"
For Data- classes, Direct inheritance is making the trick.
You can use pattern but just to order your Data- classes.
In the real world, if I join a project and see a class in
Org-AppFW-Data-MyClass
then I assume "MyClass" is used in the FW and implementations derived from it.
You can do differently, of course, but it is just a way to place your Data- classes in the application.
I do agree that: Ins-Quote-Data-Vehicle and Ins-Quote-Data-Vehicle-Car is wrong. I have no use case for this.
Damien
Updated: 14 Sep 2016 22:32 EDT
Pegasystems Inc.
US
Nothing says that Data absolutely must be object-oriented, i.e., adhere to a subtype “IsA” relationship hierarchy. See: https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
Data can also be organized as a “subsumptive containment hierarchy”. See: https://en.wikipedia.org/wiki/Hierarchy
A file system is the most common example. Beneath the root directory, where a number of files can be stored, multiple root subfolders can exist. A subfolder can contain files, as well, plus can contain its own subfolders, so on and so forth, ad-infinitum. The closer a folder is to the root, the more general it is; the farther away from the root the more specialized a folder is.
Example: Root -> Food -> Fruit -> Apple
Pattern inheritance allows what XPath calls an “ancestor-or-self” tree structure traversal. See: http://morse.inf.unideb.hu/valseg/gybitt/03/ch05.html
Using the file system analogy, suppose you are at subfolder “/Food/Fruit/Apple” and are looking for a file named “BreakfastSuggestion”. At each level a file by that name could exist.
Pattern Inheritance is the same except you would start with a class name such as Data-Food-Fruit-Apple.
Nothing says that Data absolutely must be object-oriented, i.e., adhere to a subtype “IsA” relationship hierarchy. See: https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
Data can also be organized as a “subsumptive containment hierarchy”. See: https://en.wikipedia.org/wiki/Hierarchy
A file system is the most common example. Beneath the root directory, where a number of files can be stored, multiple root subfolders can exist. A subfolder can contain files, as well, plus can contain its own subfolders, so on and so forth, ad-infinitum. The closer a folder is to the root, the more general it is; the farther away from the root the more specialized a folder is.
Example: Root -> Food -> Fruit -> Apple
Pattern inheritance allows what XPath calls an “ancestor-or-self” tree structure traversal. See: http://morse.inf.unideb.hu/valseg/gybitt/03/ch05.html
Using the file system analogy, suppose you are at subfolder “/Food/Fruit/Apple” and are looking for a file named “BreakfastSuggestion”. At each level a file by that name could exist.
Pattern Inheritance is the same except you would start with a class name such as Data-Food-Fruit-Apple.
Can direct inheritance accomplish the same goal? Sure - but which approach is more intuitive/visual when modeling a subsumptive containment hierarchy?
Going back the file system analogy, which option below would you prefer:
- A lengthy flat list of root subfolders – none of which are allowed to contain subfolders, instead each subfolder is only allowed to contain a symbolic link to its more-generic parent folder
- A short list of root of subfolders each of which are allowed to contain subfolders (which in turn are allowed to contain subfolders, etc., etc…)
?