As the 7.3 LSA course mentions, the letter "D" within the five SOLID principles stands for "Dependency injection", a.k.a., "DI". Because Pega generates Java code from developer input, it does not use the "@Inject" annotation which is fine, there is no need to.

The idea behind DI is to prevent a called object from making every decision about which "micro service" object to invoke to accomplish a certain task that is outside the called object's responsibility to perform itself. In Pega we do this through "Dynamic Class Referencing", a.k.a., "DCR".

In java, the result of using @Inject is having a field ("Property" in Pega) point to an Interface. The Interface supports a method that you want the "micro service" object to support. The construction of the "micro service" object (MSO) is handled outside the code that invokes the MSO. The main goal is that the "new" operator is never used.

What we can do in Pega instead is have a Property such as .AppExtension reference a DCR-supporting Data Page such as D_AppExtension. When spinning off a subcase and asked to supply the class name, you can choose "Other" then reference a property such as .AppExtension.NotificationClass. Different classes that implement the same NotificationClass "interface" could include Email and SMS.

Does everyone agree?