OOP: Thinking beyond verb/noun metaphor to yield a better design

Posted by Sadek Drobi on Nov 02, 2007

Sections

Architecture & Design,

Enterprise Architecture

Topics

Design ,

Architecture ,

Object Oriented Design ,

Modeling

Tags

Domain Driven Design

To describe object oriented programming, objects are often referred to as “nouns” and actions that determine their behavior as “verbs”. These verbs are traditionally implemented as methods, i.e. systematically coupled to the object that ‘performs’ the action. In a recent blog post, Reg Braithwaite points out that “not all ‘verbs’ have a clear separation between an […] active entity that ought to own the verb's definition and the secondary, passive subject entities that should not own the verb's definition”. This applies for instance to commutative operations and Braithwaite shows that, in this case, linking verbs to objects may result in “code duplication and information leakage”. He argues that it may be relevant to dissociate some verbs from nouns and raise them to the same level of abstraction as the latter:

Maybe some verbs belong to objects, but some are best on their own? Maybe + and <=> and equivalent? really ought to be emancipated from their subservience to objects and ought to have their own definitions.

Buko Obele challenges the validity of the verb/noun metaphor. He argues that, unlike real verbs and nouns, objects and methods cannot exist independently from each other:

The word 'person' in a sentence isn't dependent upon any notion of a particular verb […]. In practice we would never say that a person who can't, for example, 'run' isn't a person […]. In object oriented design concepts do not exist separately and apart from their methods at all -- instead, the whole point is that they are strictly constituted by their methods.

Moreover, in real languages the use of metaphors makes it possible to confuse “subjects and verbs and other purely syntactic concerns” in order “to produce wholly new concepts”, and this is what makes “the extraordinarily creative power of language”. In programming, there are no metaphors. Hence, objects are nothing more than very limited concepts to be combined with other concepts in order “to communicate a solution to a problem” at hand.

Even though Buko Obele argues that one should go beyond verb/noun vision, ultimately his and Braithwaite’s conclusions go along the same lines, both questioning the traditional approach to OOP. While Braithwaite provides some insights on how to decouple verbs from nouns, Obele advocates for focusing on software design that he judges inevitable “whether working with objects or functions or DSLs or even the Great Lisp” :

The question of who verbs 'belong to' is always the wrong question; instead it is always a matter of how a new concept can be meaningfully introduced into our existing system.

[…]

Any talk of nouns and verbs is useful as a starting point but ultimately you will need to do some hard thinking and engage your abstractive kung fu skills in order to describe any non-trivial system.

1. Back to top

   Coupling and Cohesion

   by Paul Beckford

   The best advice I've had about where to put methods is to keep the methods close to the data they use. So if a method needs 3 instance variables, and 2 of them are in object A and 1 in Object B, then place the method in Object A and pass the variable from Object B as a parameter.
   
   Personally I think that talk about nouns and verbs have limited use. It's a nice starting place, and can lead to nicely readable code when it all works out, but the primary drivers when coming up with abstractions should be factoring the code to avoid repetition (DRY), keeping the data close to the associated behavior (cohesion), and reducing the amount of data that needs to be passed between objects (low coupling).
   
   In the less obvious cases these rules tend to come up trumps for me. Bob Martin also has a list of OO design principles that I find useful. I also find Martin Fowler's code smells a big help too.
   
   I think the knowledge is out there and the best approaches are known, I just think that OO is taught very badly. I was playing with Dolphin Smalltalk earlier today and going through the tutorial that comes with the Community Edition.
   
   The tutorial is very good, and I would recommend it to anyone as an OO refresher. It was a real eye opener, seeing again the number of OO concepts there are self evident in Smalltalk, yet obscured or not even present in other so-called OO languages. For example the most basic concept of sending a message to an object and getting an answer is lost in early bound languages like Java, along with the benefits.
   
   IMO somewhere along the line Object Orientation got hijacked by the vendor marketing machine, and for most people today it is just another marketing buzzword.

   Reply

• Older >