Object-oriented Pega development

Consideration of Pega asset design and reuse starts with a brief mention of object-oriented development (OOD) principles, how Pega Platform™ leverages these principles, and how Pega Platform enables you to leverage the principles.

According to Robert Martin, object-oriented development encompasses three key aspects and five principles.

The three essential aspects of OOD are:

Encapsulation

Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to the object.

Inheritance

Inheritance is the ability for one object to take on the states, behaviors, and functionality of another object.

Polymorphism

Polymorphism lets you assign various meanings or usages to an entity according to its context. Accordingly, you can use a single entity as a general category for different types of actions.

SOLID is a mnemonic device for the five principles of OOD. According to Martin, OOD must adhere to these principles.

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

Single Responsibility

The Single Responsibility principle states that every module must be responsible for a single part of the software's functionality and that the module encapsulates responsibility.

The UIKit application, which contains a single ruleset, is an example of Single Responsibility.

Open/Closed

The Open/Closed principle states that software entities (such as classes, modules, and functions) must be open for extension but closed for modification. An entity can allow its behavior to be extended without modifying its source code.

The Open/Closed principle is most directly related to extensibility in Pega. If implemented correctly, an object, A, that uses another object, B, does not need to change when features are added to object B. Following this principle helps avoid maintenance-intensive ripple effects when new code is added to support new requirements. An example of the Open/Closed Principle is Pega Foundation for Healthcare's PegaHC-Data-Party class extending the PegaRULES Data-Party class.

Liskov Substitution

The Liskov Substitution principle states that objects that reference other objects by their base class need not know how that class has been extended. An example in Pega Platform is how correspondence and routing works the same regardless of the class being Data-Party-Person or Data-Party-Org.

Interface Segregation

The Interface Segregation principle (ISP) states that it is better to define multiple interfaces to an object, each fulfilling a specific purpose, instead of exposing a single large and complex interface. ISP is intended to keep a system decoupled, making the system easier to refactor, change, and redeploy. Examples of ISP in Pega Platform include service packages and parametrized data pages. Data propagation also meets the definition of ISP if a single data instance is passed as opposed to multiple, individual scalar properties.

Dependency Inversion

The Dependency Inversion principle refers to a software development technique where objects facilitate the configuration and construction of objects on which they depend. This in contrast to an object completely encapsulating its dependencies. The Dependency Inversion principle works hand-in-hand with Liskov Substitution. An example of Dependency Inversion in Pega Platform is Dynamic Class Referencing (DCR). As opposed to an object strictly using a value hard-coded within a rule’s Pages & Classes tab to create a page, a data page can be asked to supply the value for the page’s pxObjClass property.