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
Senior Software Consultant working in the Toronto area. I specialize in Microsoft technologies and have a long history of taking software development projects from idea, through development and implementation, and years of maintenance.
Always looking for interesting projects. 
Should verbs really be another class? Or should we use first class functions when they are available in the language you are using?
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.
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.”