Skip to main content

Object Only Programming (and Modelling) Considered Silly

Posted by johnreynolds on April 18, 2008 at 1:30 AM PDT

Every so often I come across a blog entry that makes my own attempts to put my thoughts in writing seem pathetically inadequate. Stevey's Blog Rant: Execution in the Kingdom of Nouns is one such entry.

Stevey's position is that Object Only Languages are silly... at least that's how I sum up his blog.

I couldn't agree more, and I couldn't have said it better... I've tried several times:

My first attempt to express my concerns about "Objects Only" was back in in November of 2003: UML and Process Definition for Java - JSR 207. Looking back, I realize that I should have just said "Object Only Modelling is a dumb idea".

For the record... "Process Only Modelling" is also a dumb idea. To borrow Stevey's metaphor, a Kingdom of Verbs is just as silly as a Kingdom of Nouns. Let's all move to the Kingdom of Sentences :-)

(cross-posted at Thoughtful Programmer)

Related Topics >>


Person steve = new Person("Steve"); steve.suspend(videogame); steve.get(garbage, sink); steve.dump(garbage, can); steve.walk(inside); steve.wash(Person.HANDS); steve.plop(couch); steve.resume(videogame); or steve.suspend(videogame) .get(garbage, sink) .dump(garbage, can) .walk(inside) .wash(Person.HANDS) .plop(couch) .resume(videogame);

The detail here is that the vocabulary is relevant only to a specific domain. I can tell my cat to take out the garbage all day long, but it's not going to happen.

The biggest issue facing, partially, albeit not completely, solved by dependency injection, is that the current popular Java idiom is POJOs and Services. POJOs don't "know" how to do ANYTHING, but Services do. So rather than having a horse that "knows" how to "shoot" itself, you need to find a service that can do it for you.

The bright side is that this kind of code turns out to be really nimble, just ugly to write.

Java has as many verbs and nouns as anyone else. If you want to make an implied global name space with a bunch of static functions in it, go ahead. Make a file that's All Knowing. g.shoot(horse). Most folks simply choose not too.


The "point" that you think Stevey missed isn't the point that I have been trying to make... (I'll leave Stevey out of this because I don't want to speak for someone else).

The point that I want to make it that the Object Oriented Modelling paradigm is often not the best way to approach the development of an application.

For example, if the application that you are developing is primarilly Process Oreinted, then you should start by developing a Process Model (using somethink like BPMN or UML Activity Diagrams).

The constructs of an implemtation language come into play when it's time to map your models to code... and that's where you may begin to understand my concerns about Java's applicability to process oriented applications (most business appications are process orieneted).

In Java Frameworks processes are almost always expressed using XML instead of Java.

JSF's faces-config.xml is a good example... The process of going from one page to the next isn't written in Java, it's written in XML.

Think about that, and perhaps you'll begin to understand why folks who deal primarilly with process oriented programs keep looking for something beyond Java.

Since my response is longer than my original post... I obviously still haven't made my point ;-)


I can't say that I agree with much in the dissertation. It is an interesting rant but it completely misses the point, OO is a way of organizing things. All languages are organized in some manner and the rules that govern that organization are what make up a grammar. As it stands today, OO is the best way of organization to organize code.

All attempts to separate representation and function have been somewhat problematic. Take EJB for example or how about JavaScript. In the most popular context is it used as a means to script behavior against a DOM. You can't take that code outside of that world and have it run even in cases when it would make sense to do so. And for anyone that has to test all of this stuff to make sure it works, it makes sense to do so.

Java may not be our purest implementation of OO. But the market/developers have rejected other forms in what I would call a reaction against something strange and unknown. The purer implementations of OO (Smalltalk for example) do look very strange. Ruby looks very strange when you compare it to C/C++, VB, and other visually similar languages. If it doesn't look like what I know I'm certainly not going to touch it. It maybe toxic or something else bad may happen.


No, NO, NO!... I am NOT saying get rid of Object Oriented Modelling. Just don't worship it as the One True Model.

There's at least a Trinity of Models that every software project needs, and maybe a whole Pantheon of Models.

Relax Felipe... relax... Object Oriented Modelling has more than enough merit to rescue itself from extinction. Nothing's going to eliminate it - But other Modelling aspects (like Process and Activity Modelling) are going to augment it.

The same is true for Java... Java is great... but it's not enough for many projects, and that's why we're adding support for a plethora of languages for the JVM. It would be silly not to.


when dynamic languages and other lousily typed dialects started to be considered the state of art in terms of simplicity, I always noticed a strong rage against OO in all that speech :)

So, behind the let's destroy Java hype is hidden the let's get rid off OO feelings :)

humm.. Object Orientation is a way to model classes of objects, and not processes. IMHO one thing has nothing to do with other :) To blame or to question OO by not well represent activities isn't fair at all..

Nowadays I am totally addictive by web-services, and I prefer to use WSDL-first development strategy, creating my OO model in pure XML files before to even create my first class :) Actually I create my business objects using XSD instead of annotated classes, but it is just my personal preference.

Eventually we can define a dialect to best describe sequence os actions, and now I recall my Master dissertation about Planning & Scheduling - a research area that uses several approaches to define planning in the most effective way as possible.

I agree with you that OO is not a good way to model actions, but I don't feel comfortable with the suggestion against Java and OO in such context ;) - specially the external blog, totally biased anti-Java and full of modernist sarcasm.. eheh

class Verb { } class Noun { } class Write extends Verb{ } class Read extends Verb { } class Arcicle extens Noun { } Noun me = new Read(Write(new Article().byAuthor("Stevey"))); Maybe more suitable terminology fo OOP is COP=Concept oriented programing. This can solve this terminology confusion. Language is very self-reflective. That's GOOD thing. THINK CONCEPTS.

Just for case of experiment someone can use import static to achieve procedural (action) style of programing.

When PD4J was abandoned in favor of BPELJ the Java community lost a golden opportunity to embrace Process Driven Design in addition to OO Design.

As a result, we've got a framework for Service Choreography (BPELJ), and a totally different framework for Page Flow (JSF)... Now that's silly.