More on Discrete Software Tools, OOP and SOA

A month ago, I commented on a post by Dan Hill about the “discrete software tools” of Unix and object-oriented programming. Shortly after, Dan emailed me and asked if I was saying that it would be a better analogy “if OOP was implemented properly” or if SOA plainly is a better analogy. Here’s my answer.

I don’t think it’s bad to have designs where individual objects are made to fit a particular context. Generally, that’s what you get if you let the designs emerge “organically”. They are “organs”, not components. This does not mean that an object should know much about the internals of other objects, just that it provides the services that neighboring objects need, rather than being designed as a completely stand-alone concept, “employee” or “paycheck”, regardless of whether anyone’s interested in the information and services it provides.

One design method that perhaps was more advocated before, but still is, says you should begin with “finding the nouns” in discussions about the reality where the future piece of software will fit in, then turn them into (discrete) concepts, where each object potentially could be used in a similar but different context. “What’s an employee?” or “What’s a paycheck?” Speaking in generic terms. Envisioning reuse regardless of whether reuse is likely.

I am in favor of the organic approach, where employees and paychecks emerge, and then can be refactored into more generic objects should the situation appear that the code would benefit another project in another context. Going deep with each and every entity is very costly and in most projects the benefits of doing this are few.

The reason I think SOA is a better analogy is that it is aimed at situations when you don’t know about future users, when you have to go deep with the question of what the service and information you are providing really is about. Your conception of something might be vastly different from someone else’s. This is evidenced by something I heard recently, from an enterprise architect of a Swedish government agency, who said that they alone had seventy-five different definitions of “address”.

But the analogy halts. The “discrete software tools” are indeed not examples of rigorous up-front conceptualizing and designing. They have evolved and been shaped by actual rather than envisioned use. But they have been used in many different contexts, and their evolution is guided by the principle that new features might be better provided by new tools rather than added to existing ones. In this regard it is more akin to the eternal virtues of object-oriented programming.