Another look at Object Oriented versus Process Driven Design

My friend Bob was troubled when I blogged "Object Only Programming is Silly". Bob knows from experience that life as a programmer after OO is dramatically better than life was before OO... so my criticisms just don't sit well with him. Obviously I must have gone off the deep end :-)

Bob's not one to let a friend languish in ignorance, so he recently appealed to my literary interests by enlisting Ayn Rand to bring me back into the OOO (Object Oriented Only) fold:

"Ms. Rand was obviously a fan of OOP, and would have likely loved Java even more than C++… not just from the name she gave her philosophy, but from its precepts and what they lead to… The Axiom of Existence leads to the Law of Identity… The Law of Causality (things act in accordance with their natures) is recognized as “the law of identity applied to action”.

“Rand rejected the popular notion that the causal link relates action to action. According to Rand, an ‘action’ is not an entity, rather it is entities that _act_, and every action is the action of an entity.”

"Therefore, you _must_ have an Object before an Action can be performed."

Thanks Bob, but with respect to Ms. Rand...

You don't care who performs the actions, you care that the actions get done.

Programming is the craft of transforming requirements into something that a computer can execute... so programmers need to focus on the requirements.

The Primary Requirement is always that the action be performed correctly and on time by a qualified entity (or entities)... so your design should be focussed on satisfying the action.

(Actions are service. Entities are service providers... nothing more)

The entity (or entities) that will perform each action is secondary, and should not be your primary focus. It falls out of the design rather than drives the design. Said another way... figure out the actions first and then you'll be able to figure out who (what enties) are required to perform them.

In Process Driven Design there is a direct linkage (via the process model) between the requirement for an action and the code that satisfies that requirement. The sequence and flow requirement are all right there in the model.

Contract this with your typical Object Model in UML... it captures the Actors...maybe... but you are left to figure out what the application actually does, unless of course you create an Activity Diagram (which isn't really OO any more.. it's behaviour).

Most programming students are now being trained to (maybe) write a use case and then start identifying objects... Then they'll create Sequence Diagrams showing the order in which objects send messages back and forth to each other.

So you've got a bunch of entities that are passing messages back and forth in some sequence... you still don't know (from looking at the model) what it is that this bunch of entities is trying to accomplish.

Contrast this with a BPMN diagram... by comparison you know exactly what the process is supposed to accomplish.

Process and Data lead to Objects. Not the other way around.

I don't disagree with Bob's insight from Ms. Rand: "You _must_ have an Object before an Action can be performed"... but I will add the precursor: You don't need an Object unless you have an Action that needs to be performed.