OOP in BPM

BPM is still something of an exotic animal compared to most other IT tools. BPM tools represent a blend of features inherent in 4^th generation programming languages with some tools such as Pega's PRPC adding a strong flavor of 5^th generation facilities. In the rush to distance such tools from the practices employed by developers of 3^rd generation (Java, C#, C++ etc.) object oriented applications, BPM developers have so far failed to emphasize those computational best-practices that still apply to application development using these new tools. The promise of these higher-level generations is to remove the programmer from the development chain; perhaps this promise precludes those mental models that require professional mentality to understand and exploit. Whatever the case, we Knowledge Warriors are clearly members of the professional caste of BPM practitioners and, as such, will need to balance best-practices in computation with business savvy.

Object Oriented Programming techniques as a computational best-practice are very much germane to our development of BPM-enabled applications. By extension, OO Design Patterns should also be part of our toolbox. For a good, basic intro to OO Design Patterns that a quasi-geek can understand, check-out the book "Head First Design Patterns" published by OReilly. For a nerdier treatise, check-out the, now classic, "Gang of Four": Design Patterns: Elements of Reusable Object-Oriented Software.

I will try to give you a brief review of this thinking and draw parallels to PRPC development over the course of the next month. Here are the major OO Design principles to be aware of with links to some detailed articles on what each one means.

The first five principles are principles of class design. For the most part these OO Classes translate into PRPC Classes. The principles are:

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.

The next six principles are about packages. In our context a package is a unit of deployment rather than of programming: usually this means a RuleSet but might also be an Application or Product collection.

The first three package principles are about package cohesion, they tell us what to put inside packages:

REP	The Release Reuse Equivalency Principle	The granule of reuse is the granule of release.
CCP	The Common Closure Principle	Classes that change together are packaged together.
CRP	The Common Reuse Principle	Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

ADP	The Acyclic Dependencies Principle	The dependency graph of packages must have no cycles.
SDP	The Stable Dependencies Principle	Depend in the direction of stability.
SAP	The Stable Abstractions Principle	Abstractness increases with stability.