Inheritance and organization hierarchy specialization
Pattern inheritance is a particular type of class specialization in an existing work pool or you can use pattern inheritance to specialize applications according to organization structure.
The Pega class naming convention is displayed in the following table. There are two optional implicit hierarchies within each class name: organization and class specialization. In the following table, a class name can use any combination of values from each of the three columns:
| Optional organization | Optional application qualifier prefix with standard Data/Work/Int prefixes | Optional class specialization |
|---|---|---|
| Org- | [App-]Data-Class | -A |
| Org-Div- | [App-]Work-CaseType | -B-C |
| Org-Div-Unit- | [App-]Int-Class | -B-D |
The following class names for case types are examples that use the pattern:
Org-App-Work-CaseType
Org-App-Work-CaseType-B
Org-App-Work-CaseType-B-C
Pattern inheritance class specialization
For example, a parent case that instantiates a child case class requires the correct information to determine which implementation class of pattern inheritance to use. The system can determine the class at run time based on the FSG-Data-Event.Category property, as shown in the following example. The parent case might also change its class to a pattern-inheriting class by using the same information.
Assuming that the number of specialized classes is relatively small, pattern-inheritance specialization enhances maintenance when using the App Explorer in Dev Studio. All pattern-specialized rules follow a grouping by class and are viewable in the App Explorer, broken down by rule category followed by rule type. The following figure shows how the Application Explorer is displayed if you extend the BookEvent case by using pattern inheritance to support Music and Seminar related events:
Organization hierarchy specialization
You can use the organizational structure of the company to specialize case types or reuse component applications by using direct inheritance.
For example, some companies are so large that you can write applications specifically for one division. The code within those applications is likely not shared with other divisions. For such scenarios, you specialize class names of case types that contain a division modifier. For example:
ORG-DIV-APP-[Work/Data/Int]-
Although rarely used, Pega Platform™ supports specialization down to the org unit level. In those situations, class names of case types contain an org-unit modifier. For example:
ORG-DIV-UNIT-APP-[Work/Data/Int]-
In this example, ORG-DIV-UNIT-APP-[Work/Data/Int]- org unit level classes could inherit directly from ORG-DIV-APP-[Work/Data/Int]- division level classes, which allows for specialization of the division-level classes at the org-unit level.
If any application in the organization can reuse component applications, you can specify the component applications as built-on applications by using an enterprise layer application.
Similarly, a specific division layer application might specify component applications that are capable of reuse by any application in a specific division as built-on applications.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?