Computers have been my hobby since I was 12. Now I'm a freelance Java developer. Like many other developers I am working on various private projects. Some are open source components (Butterfly Components - DI container, web ui, persistence api, mock test api etc.). Some are the tutorials at Yet others are web projects. I hold a bachelor degree in computer science and a master degree in IT focused on P2P networks. Jakob has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

Object Orientation is not a Goal

  • submit to reddit

I frequently read or hear people say something along the lines of "this or that is not properly object oriented", or "... function oriented", or something else similar to that. I used to utter the same statements, when I first came out of university. This kind of statement was also present in the article published here yesterday, titled "what we don't need in object oriented programming". 


Later, in the real world, I learned the shocking truth:


We do not develop software to make it object oriented, or to comply with any other paradigm.

We develop software to solve problems.


Each programming paradigm (OO, FOP, AOP etc.) is great at solving a specific type of problems, but none of them, in my opinion, is the best at everything. Therefore, I appreciate being given the choice of tools and language constructs, rather than having them dictated to me. What kind of tools or constructs I need depends on what kind of problem I am trying to solve.

For instance, why is it that in 2010, Java still doesn't have unsigned primitive types? Whenever I find myself having to do bit manipulation, I get annoyed by this. Why have I not been given the choice of what kind of primitives to use?

Along the same line, why does Scala only have object types? If I am trying to develop some software that works on binary data, I don't want Scala to optimize for me behind the scenes. I want to control it myself. If I have to do bit manipulation of large amounts of binary data, why is it, that Scala's primitive types are immutable? So, for every manipulation I create a new instance of the type? Lame.

In general, it bothers me to see elitist developers make limiting decisions on my behalf, without knowing what problem I am trying to solve. It's like saying "We know better than you what you need, so we will prohibit this or that tool / style / construct". But the thing is, such elitist thinker do NOT know better than the individual developer, what tools or constructs he or she needs to solve a given problem. To make a an analogy, this is exactly like elitist politicians who think they know best how everybody should live their lives... 

To sum it up: We develop software to solve problems, and whatever it takes to solve a given problem properly, is the "right" way of doing it. At the moment, it seems to me that the only language design camp that really gets this, is the C# team. And I'm a Java fan with 11 years of Java under my belt, so it hurts to say this. It just seems to me, that they are the only language designers that truly acknowledges the fact, that I don't need to be forced to use a certain paradigm, but be given the choice myself.

Published at DZone with permission of its author, Jakob Jenkov.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Cosmin Mutu replied on Fri, 2010/10/08 - 1:14am

:) well, nobody`s holding you at zero point with a gun ... so, go, spoil yourself with C# :) tell us how that worked out for you :)

Cosmin Mutu replied on Fri, 2010/10/08 - 1:16am

oh, and btw, the guys that develop LIBRARIES, do know much more than any average developer :) ... because, well, that`s what they do ...

Thorsten Ruehl replied on Fri, 2010/10/08 - 2:10am

Hello this is my very first comment in the java lobby forum every, so hello and good morning ;)

I like the topic that you've just touched as it was reasons for discussions at my workplace in the recent past. What i derive from my humble 4 years of field experience is that everybody would agree (so do i) on your headline that object orientation itself is not a goal. But i learned a lot of people would disagree what are actually the goals and when to use what.

My personal view on the things is that i think object orientation properly done (in our team we prefer a DDD approach) serves already several goals. It increases understandability and maintainability of code, which is essential if it has to be extended and maintained by different developers in the upcoming 10 to 15 years. The same is true for patterns and style.

This is the main disagreement that i watch the most. People can't agree that there are non-technical (if you consider extendability and maintainability as such) goals to meet and that they sometimes might even be more important than a more elegant or fancy technical solution.

How do you see this?

Eric Samson replied on Fri, 2010/10/08 - 3:02am

Seems to me you mix different concepts in the same post.

Yes, we want to solve problems, and therefore we have to think about the best ways to achieve it.

However, as you mentioned, there are generally various technical contrainsts around a project (not to mention all the non technical ones, like financial and political aspects). Sometimes fast development is key, sometimes scalability will be more important, sometimes maintenability is a must. You cannot enforce all these constraints at the same time, so you have to prioritize them and then select the most appropriate concepts / language / tools / frameworks / libraries accordingly.

And yes, designers of languages / tools / frameworks are supposed to know better than most developers what is good, just because this is their business. And yes, sometimes they fail, as everybody.

You seem to oppose OOP, FOP, AOP. I see no reason to oppose them, then can complement each others.

You also complain about fully object oriented languages. There is nothing worst than a language mixing concepts. In an ideal world int should not be more efficient than Integer. Is it just a question on how the compiler has been implemented.

The same way there is no reason why you could not optimize raw binary data manipulation in an object-oriented way. Very often, optimization is a mostly question of design and algorithm rather than syntax. You should look at optimization at a global (holistic) level. Optimizing at the syntax - line of code - level is usually not as efficient as one might expect.

IMHO, if I have no specific constraint, top 3 qualities of source code are:
  • readable,
  • correct,
  • efficient.

Being efficient is less important than being clear and readable. Even being correct is less important. You can do whatever you want with readable code: fix it, improve it, reuse it. Conversely, you cannot do anything interesting with efficient but cryptic code.
I do think, all in all, OO is one good way to achieve these goals, with the right priorities.

Just my 2 cents.
Best regards, Erix.

Nick Wiedenbrueck replied on Fri, 2010/10/08 - 3:17am

I totally agree. Lately, I tend to think, that some of these so called elitist developers are a real plague, because they make developers believe (and especially young developers) that there is some silver bullet (like OO, like MDD, like TDD, like agile, ...). But none of these are silverbullets.

It was really refreshening hearing Kent Beck say on SE Radio, that he himself sees testing quite pragmatic.

Ricky Clarkson replied on Fri, 2010/10/08 - 4:47am

Scala isn't optimising behind the scenes, but right in your face. It's quite clearly documented that Int maps to Java's int type, Double to double, etc. Scala just doesn't make any distinction between primitive and reference types, which simplifies the language quite a bit. Regarding mutability, Int and Double are just as immutable in Scala as they are in Java. Doing it differently would necessitate a massive performance hit. You're not creating new objects every time you manipulate bits. It might be worth making sure you know what you're talking about before going out and calling everything lame.

Pruteanu Ionut replied on Fri, 2010/10/08 - 6:21am in response to: Eric Samson

Eric I like your post! I think in the same way:

  • readable,
  • correct,
  • efficient.


Ibrahim Levent replied on Fri, 2010/10/08 - 10:03am

Article first part is OK, but when it comes to Java, I can't agree with that. All parts of a software don't need to be object-oriented, for example databases. But in language context, it should be a goal. OOP is a proven technology. The mistake is to try to make every software artifact object-oriented. "C# team praise" in Javalobby is odd.

Mark Haniford replied on Fri, 2010/10/08 - 11:14am

Clojure isn't Object-oriented, but it has more powerful polymorphic capabilities (e.g. multiple-dispatch) than Java. 

J Szy replied on Fri, 2010/10/08 - 1:26pm

For instance, why is it that in 2010, Java still doesn't have unsigned primitive types? Whenever I find myself having to do bit manipulation, I get annoyed by this. Why have I not been given the choice of what kind of primitives to use?

Why is it that in 2010, Java still doesn't have fully functional goto? Whenever I find myself having to jump to another location in code, I get annoyed by this. Why have I not been given the choice of what kind of flow control to use?

Gee, Java doesn't even have line numbers that Basic used to have thirty years ago!

We develop software to solve problems, and whatever it takes to solve a given problem properly, is the "right" way of doing it.

You could make good with just a hex editor. Other than that, every platform imposes its own restrictions, and you have to just live with it.

Besides, not having some feature may be (and more often than you'd expect is) an advantage. Think of goto or pointer arithmetics - perhaps there are situations where they'd be the best tools to use, but they are so prone to abuse that it's simply better not to have them at all.

Paul Topping replied on Fri, 2010/10/08 - 3:09pm

Rather than .NETs multiple languages built on a common runtime, I would prefer a multi-paradigm programming language. See It would be nice to be able to apply object-orientation, functional, data-flow, logic, ... wherever needed and in combination, but I don't want to learn 5 programming languages, IDEs, compilers, build systems, etc. to do it.

Liam Knox replied on Fri, 2010/10/08 - 5:53pm in response to: Paul Topping

Tower of Babel. 500 crap languages built on an OS that doesnt work. Rather than 1 language that works on all.

Andy Bel replied on Fri, 2010/10/08 - 9:33pm in response to: J Szy

Don't feel you have points

goto - is workaroundable with using while/for/if/switch

line numbers - you can setup IDE to show them

pointer arithmetics - can't imagened how it can not be workaroundable

unsigned types - is workaroundable, anyway bit operations doesn't care about sign

non-existence of primitive types - is not workaroundable in theory

but in practice you can write a java library and used from Scala

 So far so good.



J Szy replied on Sat, 2010/10/09 - 2:05am in response to: Andy Bel

Don't feel you have points


I don't feel you understood my comment.

cowwoc replied on Sun, 2010/10/10 - 12:49am

This article and the comments below are hilarious. It seems to me that you should go use C# and Perl for a few years and get back to us.


As for me, I believe "less is more" :)

Josh Marotti replied on Mon, 2010/10/11 - 3:01pm

I understand where you are coming from.  You are on a difficult project where a simple answer is to just pound it out and avoid an OO concept.  And for that, you are right.  You shouldn't be constrained from "fixing the damn thing" or finishing the project, whether that contraint is OO or DDD or whatever.


However, there is such a thing as too much!

If you go back many years and code without OO, you'll find a lot of work being redone time and time again.  These mythical 'all OO' or 'completely reusable objects' is a goal we strive for so we can write LESS code next project, because we have reuse.  Reuse means a lot, too!  It means readability, learning curve (use the same business logic in 5 different places, more people understand it, and there is no learning curve to try and code it yourself or use the logic again), and, believe it or not, reuse (the more reusable code you have in a project, it usually 'forces' you to make your custom code reusable as well).

So, while I agree with you, that you CAN avoid pie-in-the-sky design principles, and you SHOULD avoid them when it is a small problem you need to fix and doing it the 'good/right' way makes the job 50 times harder, you shouldn't abandon the use of them, entirely.  They were developed after decades of developers got frustrated with the way code was written.  Having said that last line, perhaps you are frustrated enough to come up with a new design principle or method that doesn't abandon what we've used for decades, but is built upon it to solve its flaws?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.