May 18, 2014

Is Java a 100% Object Oriented (OO) language? if yes why? and if no, why not?

This is a very common Java interview question. Here is the detailed answer to impress your interviewers.

A. I would say Java is not 100% object oriented, but it embodies practical OO concepts. There are 6 qualities to make a programming language to be pure object oriented. They are:

1. Encapsulation – data hiding and modularity.2. Inheritance – you define new classes and behavior based on existing classes to obtain code reuse.3. Polymorphism – the same message sent to different objects results in behavior that's dependent on the nature of the object receiving the message.4. All predefined types are objects.5. All operations are performed by sending messages to objects.6. All user defined types are objects.

Reason #1: The main reason why Java cannot be considered 100% OO is due to its existence of 8 primitive variables (i.e. violates point number 4) like int, long, char, float, etc. These data types have been excused from being objects for simplicity and to improve performance. Since primitive data types are not objects, they don't have any qualities such as inheritance or polymorphism. Even though Java provides immutable wrapper classes like Integer, Long, Character, etc representing corresponding primitive data as objects, the fact that it allowed non object oriented primitive variables to exist, makes it not fully OO.

Reason #2: Another reason why Java is considered not full OO is due to its existence of static methods and variables (i.e. violates point number 5). Since static methods can be invoked without instantiating an object, we could say that it breaks the rules of encapsulation.

Reason #3: Java does not support multiple class inheritance to solve the diamond problem because different classes may have different variables with same name that may be contradicted and can cause confusions and result in errors.

In Java, any class can extend only one other class, but can implement multiple interfaces.

We could also argue that Java is not 100% OO according to this point of
view. But Java realizes some of the key benefits of multiple
inheritance through its support for multiple interface inheritance and
in Java 8, you can have multiple behavior (not state) inheritance as you can have default methods in interfaces.

Since this is a kind of polymorphism for other operators like * (multiplication), / (division), or - (subtraction), and Java does not support this, hence one could debate that Java is not 100% OO. Working with a primitive in Java is more elegant than working with an object like BigDecimal. For example,

int a,b, c;
//without operator overloading
a = b – c * d

What happens in Java when you have to deal with large decimal numbers that must be accurate and of unlimited size and precision? You must use a BigDecimal. BigDecimal looks verbose for larger calculations without the operator overloading as shown below:

Also, the last line above is wrong. The rules of precedence have changed. With chained method calls like this, evaluation is strictly left-to-right. Instead of subtracting the product of c and d from b, we are multiplying the difference between b and c by d. We would have to rewrite the last line as shown below:

BigDecimal a = b.subtract(c.multiply(d)); //correct

So, it is error prone as well. Another point is that the BigDecimal class is immutable and, as such, each of the “operator” methods returns a new instance. In future Java versions, you may have operator overloading for BigDecimal, and it would make your code more readable as shown below.

BigDecimal a = b – (c * d); //much better

This blog post has covered OO basics, Daiamond problem, and operator overloading concepts as well with examples.