Goo Code

(Generic Object-Oriented Code)

Goo as in goo-goo-ga-ga, the sound a baby makes, implying simple and naive.

Extreme Programming says to do the simplest thing that could possibly work. Many programmers today use object-oriented programming languages. Numerous software pattern books exist, each listing object patterns that are solutions to problems that are encountered while coding, some frequently, some rarely.

But what about the generic case? Can we articulate a “generic” object coding problem? Something like “the coding problem that exists in the absence of any other recognizable coding problem”?

More to the point, can we describe a “generic” object pattern? Something like “the pattern to try first, in the absence of any other recognizable pattern to try?”

Such a generic pattern should be simple, and have a decent chance of working, to satisfy “do the simplest thing that could possibly work”. Let’s give it a try…


GooCode

You start a new coding task. The task is plain vanilla, and has no recognizable special cases.

Therefore, create GooCode (generic object-oriented code). Listen to the customer, read the user stories, and talk about the problem. Naively create one class for each domain concept you hear about, and naively hook the classes together the way you hear the domain concepts are hooked together.

For each responsibility or action you hear about, naively create one method, and attach it to the class that is most affected by the method. (Writing the test for the method first, of course). Get the method to work, then repeat.

Orders have order lines? OK, class Order has an instance variable called orderLines. The window has an entry text pane and a display text pane? OK, we make class TextPaneEntry and class TextPaneDisplay. There is a database? OK, we make class Database. The customer has a mailing address and a billing address? OK, we make class Customer, with an instance variable mailingAddress that points to an instance of class Address, and an instance variable billingAddress that points to an instance of class Address.


That sounds like a very interesting idea.

Actually, it sounds to me like a pointless statement of the obvious. It sounds like a good example of a got-a-hammer-everything-looks-like-a-nail pattern, of thinking that everything is a pattern, even when it's not. Why should we "articulate a 'generic' object coding problem"?

It sounds interesting, I should have qualified, because it

If this base case is obvious to you, then I accuse you of not pointing it out before, because I have not heard of this pattern earlier. And by the way: EverythingInMathIsTrivial? or EverythingIsObviousWhenUnderstood?. -- GunnarZarncke


CategoryPattern


EditText of this page (last edited November 24, 2005) or FindPage with title or text search