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

[australian-joe.livejournal.com]

Hmmm, interesting stuff there.

I don't code anything more complex than SQL or shell scripts, so perhaps I don't have that bias to unlearn here. 8->

However I really wanted to applaud for

[...] 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)

It's been my experience that it's very rare for application developers to make those distinctions. Tuning database performance is much of my work and I regularly find myself giving developers the "cup of coffee rant":

A database transaction should be as absolutely small as possible. It's defining what the business says is atomic - so if you dared attempt to split this business process into any smaller tasks, you'd lose your job, get sued or go to jail. Transferring money from one account to another is a suitable database transaction - it is (I hope) inconceivable that a bank teller could debit the source account and then go to lunch! But reconciling balances for all accounts is not a database transaction - reconciling my account has no business dependency on reconciling yours. There's no place for human interaction in a database transaction. If the phone rings in the middle of it and you can pick the phone up, it isn't a database transaction. If you're allowed to go get a cup of coffee while it runs, it isn't a database transaction.

Ahem. Yes, the "whack everything into a single database transaction" causes much grief at the database level, and usually seems to be the result of lazy programming where "it's all too much trouble to deal with detecting partial failures and resubmitting".

[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.

[king-tirian.livejournal.com]

Oh d-d-dear. My brain says that the transfer is its own object like you. But it's because I'm wanting to model the slip of paper that you hand the teller where you fill out the details of the transaction. Like I needed more evidence that I'm a deficient OO programmer.

[nolly.livejournal.com]

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