I thought it would be a really good idea to share interesting interview questions, especially the ones that caught me off guard!
I found this title to be a very interesting question… I’m not sure it was intended as an open-ended question, as I don’t think there is a right or wrong answer. It really depends on your perspective. Are you looking at it from a purely technical or logical (modeling/solution) perspective? Even though I might be considered very technical, I prefer to stay out of the really low level stuff. Sure it is fun, to get down to the bare metal once in a while, but I get more enjoyment out of the thought process. Claiming to be a very Object Oriented person and stumbling on this question really bothered me… I came home and did some Googling, but really never found the answers that seemed to live up my expectations. Next, I sent an mail to one of my pals who just loves the nuts and bolts… In his typically witty way, he rattled off: int, float, boolean, double, long, and char. A completely valid answer! He then have me six other bullets which I have merged into the table below and tried to expand upon.
| Reason | Explanation |
| Primitives | The interviewer lead me with this one, which it is actually pretty obvious when you think about it! This is really not disputable, primitives are not truly objects. I think for historical reasons, namely performance and ease of use, developers were pushed to primitives. With modern JVMs and Java 1.5 autoboxing, I feel like this flaw is slightly minimized. However, from a purest OO perspective this is a valid reason. |
| Constructors | The interviewer also talked about the limitation where constructors can only return an instance of itself, the specific class; which has lead to the creation of factory patterns and DI frameworks. Having been a Spring Framework fanatic for so many years, I have probably developed a different style of programming which as shielded me from this issue. With some of the more dynamic OO languages, you can apparently return a different type instance from the constructor. I need to study some more on this, but did find an interesting Ruby thread. Ruby is definitely on my learning list, so I have to stop blogging! |
| First Class Objects | This reason takes us to pure object orientation. I’m going to gloss over this a little and let you read more on your own as I did today, try this simple search. One of the more obvious distinctions, would probably be the meta data / class model provided by Java. |
| Statics | This is actually one of my pet peeves. I am a no fan of static methods. For me it is simple, statics equal functions which equal non object oriented. I have always bought into the DI propaganda which states that static objects and methods are untestable, which I fundamentally agree with. However, I did recently discover there are are several mocking frameworks that can actually mock out static classes and methods. This is pretty cool, but unnecessary in my preferred design and implementation style. |
| No Multiple Inheritance | Coming from a C++ background, this was always a big discussion point. I generally did not recommend multiple inheritance, as it was tricky and usually implemented (and even modeled) inappropriately. I was much more interested in inheriting behavior rather than state. If I remember correctly, this is where it got interesting using C++. Java Interfaces do a little bit to address this issue, but there is typically no why to elegantly solve the problem without a little code duplication and/or helper classes. |
| Strings | My nuts and bolt friend gave me this one; not sure where he was going, but obviously the Java String class is its own unique creation. Personally, I was always bummed by the lack of a mutable String class. I might have prefer to see non-mutability implemented via subclasses, or something like the Collections.unmodifiableCollection() method. How about that, another static method reference! Maybe this would have been a little better, stringInstance.getImutable()! |
| Limited Operator Overloading | Having done a lot of C++ in my early programming career, I found elegance in operator overloading and saw it as a void in Java. But, I do have to agree with the reason it was left out of Java, “it was used incorrectly to many times in C++”. Unfortunately, you can use any tool incorrectly; it might have been nice to let us decide if and how to use some of these features, rather than eliminate them. I did find an interesting thread on StackOverflow, so I will keep my thoughts short! |
| JNI | This was another bullet from my nuts and bolt friend. In my opinion, JNI was more of a Java after thought, “bolted-on” to simply to take advantage of existing solutions and provide some level of extensibility. I have not used JNI for many years, and all I can remember is procedural nature of our solution. I don’t remember details, other than it was ugly! You could also say that ugly is not object oriented! |
| Package Level Scope | Late breaking addition. I personally never liked the “package” level scoping provided by Java. How is this object oriented? You are basically breaking the class level encapsulation, allowing all classes in that package access… This always felt like a little implementation hack to me… not one of my favorites! |
My thoughts might not be completely baked, but I need to keep on moving; so please let me know if you think I missed the point! Generally speaking, I have been very happy with Java as a implementation language. All languages have their warts, and Java is no different. The vast number of tools and frameworks allow Java applications to be effectively developed, tested, and deployed. I also believe that Java is pretty forgiving, allowing developers of all levels to build solutions; from being barely object oriented to insanely obscure. Hopefully, we end up in the middle with simple elegance. I hope to have the opportunity to explore some of these Java flaws in a Ruby, so please check back and see what I have learned!
February 6th, 2011 6:17 am
No idea why you think that function pointers/closures are requirement for being ‘Object Oriented’, why immutability (String) is not OO, how operator overloading has anything to do with OO and best part – JNI. Do you also consider java to be non-object oriented because it can run on processors which execute non-object oriented microcodes internally?
Please do not mix “Why java is not pure OO language” with “What I don’t like about java”.
February 6th, 2011 7:32 am
Artur, thank your for you reply. I can definitely see that I mixed in a lot of personal preferences and I should be more conscious of where I add those statements in the future.
My real thought concerning the immutability of a String, is it feels similar to a “constant” object; it has state and behavior, both which are unchangeable. It still has OO properties, but they seem to be limited. That goes along with my friends clarification of his original bullet list: “The the problem with String is not just with String, it is the tendency of library classes to be final. An Object Oriented language would let you do something like TomsString extends String. Having so much of what is *effectively* part of the language be walled off from OO use is the issue.”
I completely disagree with you on operator overloading. In its truest sense “overloading an operator”, is about extending the behavior of an object, providing a specific behavior for that operation. That seems to imply that I should be able to overload the core operators as well. It might be seen as unnecessary and problematic by some, I believe it is a OO shortcoming within Java.
February 6th, 2011 7:46 am
At firt the question (and the responses) are interresting. It’s good to do a little reasoning on a language we use daily.
The problem then is that most points are rethorics.
We don’t need a pure OOP language. We don’t even need an OOP language by default. Theres things are modelization of computer science. They have no reality. In the sence of, if the model isn’t good to solve a problem, you change the model, you don’t change the problem.
We need a good language. And this may require a strong OOP support.
But the reality is that OOP fit well some problems, and is really bad or subotimal for others problems. So theses concept of pure OOP or wondering if a language is really object oriented or not is useless.
For exemple facades. You just need to provide a clean public API, and you don’t care at all about OOP here. In fact a facade is a list of procedural functions. Nothing to do with OOP. You may use an interface or inheritence to mock your facade when testing, but you use OOP here as a technical tool. And no, interfaces are not OOP. This is just a specification contract. Nothing more.
Many people use inheritence to reuse code. They make huge class hierachy, trying to reuse code and make fragile, complex code that is difficult to maintain. Inheritence make so much coupling between classes that you can’t change a class implementation without risquing to compromise the whole inheritence tree. In huge codebase, this is a real plague.
Overengineering : Some people love so much OOP and design patterns than they can’t keep things simple.
They like to restrict visibility because at time of design they think that nobody would need to access this thing. And of course, the time always occurs when somebody really need to access the field/method. Maybe for serializing the object, maybe to extend a functionnality, maybe for doing some unit testing. But because the visibility is private so much time is lost trying to bypass the limitation. If you don’t have the right to change the code, you are restricted to decompile the class, make you own modified version of the code to be loaded instead of the initial one. Maybe you’ll use introspection…. Hugly. Just for the sake of someone pureness. To feel good when designing.
The worse is that theses people will use getters/setter everywhere and so break encapsulation of their private fields without even thinking of it. This is just some sort of baked way of programming and people don’t even think about what they do when doing it.
Other always think that you have to be generic and extentable. They add interfaces eveywhere, use lot of patterns just for the sake of showing how smart they are. Why not use the observer pattern ? Is it so much more difficult to understand and maintain the code !
Hey I am sure adding an abstract factory there, despite there is only one possible implementation of the class would be good… in case of.
You want to access a database ? Hey 1 line of SQL is so old school. Really, make an UML model on a modeling software that unable to deal with correct version control and in fact prevent you that 2 people on any branch of the project work on the model at the same time.
Then, generate one thousand line of useless boilerplate code. Code that would not even need in the first time by using some sort of ActiveRecord. You can even have LazyLoading exception and perform dozen of sub request without even realizing it.
The best is to embedd inheritence in your datamodel so your are sure to really kill application performance ! The beauty of all of this… When you need to perform complex request, your only choice is to go doing to plain old SQL. And it perform like 100X faster.
February 6th, 2011 8:40 am
I think the quesiton should be “Name Five reasons Java is not PURELY Object Oriented?” Correct me if i am wrong.
February 6th, 2011 11:47 am
[…] This post was mentioned on Twitter by Eng Bernie, Ibrahim Saracoglu. Ibrahim Saracoglu said: Interesting interview question… Five reasons #Java is not Object Oriented? http://bit.ly/gXMsDN […]
February 9th, 2011 5:19 am
Thanks for this great article!!
March 16th, 2011 5:04 am
[…] https://www.beilers.com/2011/02/interview-question-name-five-reasons-java-is-not-object-oriented/ Posts Relacionados:Linguagens em 2011 Com o início de 2011, algumas …Linguagens de Programação […]
March 17th, 2011 5:06 am
Java is nothing but a shell to cover the dialect of C + +
Digital Mars D language is object oriented …
May 31st, 2011 9:29 am
[…] https://www.beilers.com/2011/02/interview-question-name-five-reasons-java-is-not-object-oriented/ Click here to cancel reply. Name […]
July 20th, 2011 3:31 am
Regarding operator overloading and dynamism of a language, there are two things
1) Trusting Program
2) Trusting Programmers
Java is a blunt scissor, where it shells clearing all the noisy memory allocations, preventing leaks, not leaving state of an object stale, there by enabling average programmers to code better rather than brainees coding in C++, or Python.
You can trust even a worst java program where JVM will come to rescue, and for Python and Ruby programmers have full freedom to do anything, and we trust their diligence
Moreover, Encapsulation is something you define with in the classes, and nothing to do with the package. I usually encapsulate to avoid duplication, provide security, avoid null properties