No One Writes OO Anymore

Thingie.doSomething

"O Romeo, Romeo! Wherefore (why) art thou Romeo?"

...

"What's in a name? That which we call a rose

By any other word would smell as sweet." - Juliet in "Romeo and Juliet"

2008/03/23 It never ceases to amaze me: the lip-service paid to OO (object-oriented design and programming). In recently designed software systems, and in respected training books whose authors should know better, one sees objects (classes) with names like "PlaceItemWithDAO" in which the object name starts with a verb!

Very little rigor or thought appears to be given to the OO naming these days, but the foundational rule, straight from the Sun Java Coding Standards, is, and always has been, simple and common-sense, and will go a long way toward helping new programmers and non-technical managers understand your system:

Object (class) names should be nouns; they tell what the objects ARE. Method names should be verbs; they tell what the objects DO.

But having accepted that premise, one of the great challenges of OO design and programming is to come up with real-world analogies, so that one can form useful, meaningful names for objects and methods.

In the world of visual game programming, from which I imagine OO got its true start, this is easier, and most OO training examples use game design names. This helps newbies more easily make the jump to the abstract world of programming. Thus we see Dog.sniff and Car.turn as object and method names in the newbie training examples. But coming up with names for, say, "the processing of nightly batch reports into XML for fail-safe transmission to a B2B client on a server in Australia"...is more difficult. I mean, the best the Struts designers could come up with was "ActionController.execute"? How meaningful is that as an object and its method? Why not just name it "ThingThatDoesSomething"? And how many different contextual meanings can we attach to the nouns "document" or "service" or "transaction" or "request" or to the verbs "execute" or "process" or "request"? They are so vague, and so overused, but what choice is there when the software concepts they represent are so abstract and yet so prolific?

There is no perfect answer that I know of, but one way of designing that helps, is to take some up-front time, and using your imagination, visualize a real or contrived analogy in the real world. After all, the "P" in JSP (Java Server Pages) is an analogy for a page made of paper, with which most humans are familiar and to which it bears some resemblance...certainly more resemblance than a "page" of memory :-).

Or take this example: Assuming that today I gave you 10 minutes to read and memorize the API (object's) documentation, 10 years from now, if I asked you to tell me what ActionController.execute does, and then tell me what Dog.sniff does, which would you have an easier time visualizing and remembering?

Since I have always thought of computer programs as little people inside the machine, running around in there doing the work, back in 2000, on my first big OO design, I came up with the idea of a Manager object whenever I could not reasonably give responsibility to a "lower" object, such as a Policy object or an Auditor object. A manager, in the human world, often has to interface with many people, wear many hats and understand many jobs, and by default, do the jobs that those under her cannot. I figured it was not much of a jump to translate that into a software analogy, and I notice other systems these days also use the "people manager" analogy, although there are now probably some better analogies.

My point is that people think visually - if they didn't we wouldn't need whiteboards - and imperfect as some analogies may be, in order to effectively communicate a design, we need a clear connection to something we already understand, something that already exists the real world. With that connection, we can make instantaneous mental jumps to the inherent abstractness of software designs. But without such concrete, easy-to-visualize analogies, the object and method names are just all over the place, and we might as well go back to the 70's and call our objects "OB125"...or ActionController.execute...or Thingie.doSomething.

If you are going to use OO, take full advantage of its innate power. Unfortunately, this takes some artistic imagination, something with which most software designers, myself included, are not naturally gifted, but fortunately, this is where the bright, artistic but non-technical users of the system can have great input into the design. Maybe some modern-day Shakespeare will step forward and help us out.