While I Compile

… I compile my thoughts about programming

What’s wrong with the noun/adjective/verb object oriented design strategy

The programming course I took way back in 1993 was basically a 1 year intro to C. And like any good student, as I learned the language, I also started learning about code reuse and experienced a delightful satisfaction every time I realized 2 different functions had similar code which could be moved into a new function.

Eventually, I noticed a pattern, in that I would write a bit of functionality until it worked, then I would refactor it into a more elegant solution with as little repeated code as possible.

My code evolved quite nicely.

Then I learned C++, object oriented programming, and was introduced to the holy grail of object oriented design advice, which went something like this:

Take your requirements and circle all the nouns, those are your classes. Then underline all the adjectives, those are your properties. Then highlight all your verbs, those are your methods

This Noun / Adjective / Verb design strategy seemed like the most ingenious piece of programming wisdom ever spoken … but it’s led us down a misguided path.

It’s the verb that’s misunderstood. The verb should be another class, not a method. It should be a process class. As a programming concept, a process is just as much a ‘thing’ as any real world object. The verb should be a class, which accepts the noun as an input to be processed.

But there’s also another problem; Up until this little shortcut was articulated, code was structured based on the implemented code, with similar functionality refactored into its own reusable units, but once noun/adjective/verb idea became widespread, code was suddenly structured according to domain.

For example, the domain focus was really evident in the way we structured our ‘is-a’ relationships, with inheritance being based more on the real world domain, than the implementation code.

Inheritance should be based on most efficient code reuse, not the domain, because as anybody who has heard the square is not a rectangle* example can attest, sometimes the domain ‘is-a’ relationship just doesn’t work.

* With regards to the square is not a rectangle example, please be aware the solution outlined does not resolve the problem, as described in Uncle Bobs comment. The 1996(?) magazine article, The Liskov Substitution Principle is available, which contains the example as originally described. I didn’t post this url, since it’s not focused exclusively on the square / rectangle issue.

Copyright © John MacIntyre 2010, All rights reserved

About these ads

August 1, 2010 - Posted by | Programming | , ,

3 Comments »

  1. Should verbs really be another class? Or should we use first class functions when they are available in the language you are using?

    Comment by Matthew Closson | September 3, 2010

  2. Yeah, it can be a first class function or static method, or class. Depending on the language and complexity of the functionality.

    The point was mostly; I no longer think it should be a method on the same class as the data is based in.

    Thanks for the comment.

    Comment by John MacIntyre | September 3, 2010

  3. The process of conflating nouns with verbs to form “objects” is logically weaker than building software where data and procedures are not confounded with one another, such that operators and operands are kept separate as in procedural programming.

    As systems are scaled up in complexity, the nature of the interconnections used to unite the parts is the most important factor in determining overall system reliability. Just as you can’t build skyscrapers out of straw, you can’t support large-scale software by using weak logic to connect the parts.

    The essential problem with the so-called principle of “information hiding” is that it runs counter to control theory which requires that the state of a system must be observable in order for it to be controllable. OOP breaks down step-by-step by incrementally encapsulating the very information needed to maintain control of the system. The long run state of a large OOP project is chronic instability as the system passes from closed loop behavior into open loop chaos.

    There’s no substitute for understanding, and for that you need information. “Nature to be commanded must be obeyed.”

    Comment by Tim Lee | December 26, 2010


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: