Awwwwbjects

[bcholmes]

Several years ago ago, I read this article written by a senior programming consultant. He recounted a story of going in to an organization and designing some code. He was explaining some process classes in his design to another programmer who rebuked him: "Maybe you don't know, but we use awwwwbjects here. Functions are supposed to methods on awwwwbjects." I remember the really funny spelling of "objects".

The whole point of the article was something that I've found myself parroting a lot, lately: that many object-oriented programmers are thing-biased. Too many OO programmers don't see processes as proper classes.

Case in point: as an OO development team what their business model looks like, and nine times out of ten, they'll draw something that's essentially an entity-relationship diagram. Persons have one-or-more Names and Persons have one-or-more addresses, yada yada.

But: where are the business processes in such models? They usually don't exist as specific classes. People are always trying to coerce processes into other object types (or, more often than not, into side-effects of the user interface).

Take an example. Banking. Deduct $50 from a bank account. Some people would create an Account.deduct(BigDecimal amount) method. Okay. Now how about transfer from one account to another? Which object is the target of that method call? Answer: the transfer is itself an object that collaborates with two Account objects.

Another example: think of the strategy pattern. A strategy is a class that implements a rule or implementation of a function. It's a small process object.

I remember in a previous job, we used an interesting taxonomy of processes. Everything from the entity method, to the fast transaction (generally a business function that's implemented in one database transaction) to the task process (a business function that has several discrete steps with waits for human interaction between them) to the workflow process (a business function carried out over the span of days). There was a real a-ha moment to this concept. Developers took a long time to get it.

Just the other day, I read an article on service-oriented architecture (aka, SOA, the latest buzz-word in the CIO magazines), and found this paragraph:

The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

What? That's one of the stupidest things I've ever heard. Services are, essentially, processes. Processes have their own data (e.g. data about the person who performed the process, the state of the process, etc.) SOA doesn't depart from object oriented programming at all. What it departs from is the limited vision of some object-oriented programmers who are blinkered into thinking about objects as real-world things.

Geez, louise. Where do people learn OO these days?

Comments

[nolly.livejournal.com]

If process objects had ever been mentioned by anyone who tried to teach me OO programming, I'd've taken to it much more strongly. Most of what I dislike about OO is exactly the sort of kludge you describe.

[nolly.livejournal.com]

Oh, and the way I was taght, that'd be
SourceAccount.transfer(amount, DestAccount);