Object-oriented Pega development

The three essential aspects of object-oriented development are:

• Encapsulation: The ability to hide the values or state of a structured data object inside a class, preventing the direct access of unauthorized parties to the object.
• Inheritance: The ability of one object to take on the states, behaviors, and functionality of another object.
• Polymorphism: The ability to 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 the following 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 Theme-Cosmos 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 extend its behavior without modifying its source code.

The Open/Closed principle is most directly related to extensibility in Pega Platform. If implemented correctly, an object, A, that uses another object, B, does not need to change when object B receives new features. Following this principle helps avoid maintenance-intensive ripple effects when developers add new code to support new requirements. You can find an example of the Open/Closed Principle in Pega Foundation for Healthcare™, where PegaHC-Data-Party class extends 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 the system extends that class. An example in Pega Platform is how correspondence and routing work 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. The purpose of ISP is 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 technique is in contrast to an object that completely encapsulates 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 that uses a value hard-coded on the Pages & Classes tab of a rule to create a page, the system can ask a data page to supply the value for the pxObjClass property of the page.

Check your knowledge with the following interaction: