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 unauthorized parties from directly accessing the object.
• Inheritance: The ability of one object to inherit the states, behaviors, and functionality of another object.
• Polymorphism: The ability to assign various meanings or usages to an entity according to its context. 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 should be responsible for a single part of the software's functionality and that the module should encapsulate that responsibility.

The Constellation implementation, which contains a single Ruleset, is an example of Single Responsibility.

Open/Closed

The Open/Closed Principle states that software entities, such as modules and functions, should be open for extension but closed for modification. An entity can extend its behavior without modifying its source code. 

The Open/Closed principle is 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.

Liskov Substitution

The Liskov Substitution Principle requires that objects of a superclass must be replaceable with objects of its subclasses without causing any disruption to the application. This principle is based on the contract defined by the methods in the superclass, which every subclass must comply with. If a subclass fails to meet the requirements of the superclass's contract, it violates the Liskov Substitution Principle.

For example, in Pega Platform, correspondence and routing work the same way regardless of whether the class is Data-Party-Person or Data-Party-Org, as shown in the following figure:

Interface Segregation

The Interface Segregation Principle (ISP) states that defining multiple interfaces to an object, each fulfilling a specific purpose, is better than exposing a single large and complex interface. The purpose of ISP is to keep a system decoupled, which makes it easier to refactor, change, and redeploy.

The list of APIs in Pega Platform offers separate APIs for each functionality aspect instead of combining all functions into a single API. For example, there is a distinct API for Assignment, another API for Assignment with ID, and a separate API for when you have an action ID. Similarly, there are separate APIs for Perform, Refresh, and Save Assignment actions instead of grouping them all into a single API.

Dependency Inversion

The Dependency Inversion Principle (DIP) refers to a software development technique where objects facilitate the configuration and construction of things on which they depend. In general, an object is an instance of a class that encapsulates all its attributes and dependencies. However, in DIP, an object can change its class or interface at run time according to the need.

An example of Dependency Inversion in the Pega Platform is Dynamic Class Referencing (DCR). As opposed to an object 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: