PEGAFREAK Member since 2013 9 posts
Bank of America
Posted: September 2, 2016
Last activity: September 14, 2016

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-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***


Moderation Team has archived post
Share this page LinkedIn