Over a million developers have joined DZone.

Object Orientation is not a Goal

DZone's Guide to

Object Orientation is not a Goal

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

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.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}