here my Question it is said that "Java is not actually a pure object oriented programming language since it needs primitives" I want to know that how data types can affect to java be an pure object oriented Langugae ?
There are various different definitions of what it means to be "object-oriented", but it turns out that all of those definitions are just approaching the problem from different angles and actually agree with each other.
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
Let's break that down:
- messaging ("virtual method dispatch", if you are not familiar with Smalltalk)
- state-process should be
- locally retained
- extreme late-binding of all things
Implementation-wise, messaging is a late-bound procedure call, and if procedure calls are late-bound, then you cannot know at design time what you are going to call, so you cannot make any assumptions about the concrete representation of state. So, really it is about messaging, late-binding is an implementation of messaging and encapsulation is a consequence of it.
He later on clarified that "The big idea is 'messaging'", and regrets having called it "object-oriented" instead of "message-oriented", because the term "object-oriented" puts the focus on the unimportant thing (objects) and distracts from what is really important (messaging):
Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.
The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.
Messaging is fundamental to OO, both as metaphor and as a mechanism.
If you send someone a message, you don't know what they do with it. The only thing you can observe, is their response. You don't know whether they processed the message themselves (i.e. if the object has a method), if they forwarded the message to someone else (delegation / proxying), if they even understood it. That's what encapsulation is all about, that's what OO is all about. You cannot even distinguish a proxy from the real thing, as long as it responds how you expect it to.
A more "modern" term for "messaging" is "dynamic method dispatch" or "virtual method call", but that loses the metaphor and focuses on the mechanism.
So, there are two ways to look at Alan Kay's definition: if you look at it standing on its own, you might observe that messaging is basically a late-bound procedure call and late-binding implies encapsulation, so we can conclude that #1 and #2 are actually redundant, and OO is all about late-binding.
However, he later clarified that the important thing is messaging, and so we can look at it from a different angle: messaging is late-bound. Now, if messaging were the only thing possible, then #3 would trivially be true: if there is only one thing, and that thing is late-bound, then all things are late-bound. And once again, encapsulation follows from messaging.
Similar points are also made in On Understanding Data Abstraction, Revisited by William R. Cook and also his Proposal for Simplified, Modern Definitions of "Object" and "Object Oriented".
Dynamic dispatch of operations is the essential characteristic of objects. It means that the operation to be invoked is a dynamic property of the object itself. Operations cannot be identified statically, and there is no way in general to exactly what operation will executed in response to a given request, except by running it. This is exactly the same as with first-class functions, which are always dynamically dispatched.
In Smalltalk-72, there weren't even any objects! There were only message streams that got parsed, rewritten and rerouted. First came methods (standard ways to parse and reroute the message streams), later came objects (groupings of methods that share some private state). Inheritance came much later, and classes were only introduced as a way to support inheritance. Had Kay's research group already known about prototypes, they probably would have never introduced classes in the first place.
Benjamin Pierce in Types and Programming Languages argues that the defining feature of Object-Orientation is Open Recursion.
So: according to Alan Kay, OO is all about messaging. According to William Cook, OO is all about dynamic method dispatch (which is really the same thing). According to Benjamin Pierce, OO is all about Open Recursion, which basically means that self-references are dynamically resolved (or at least that's a way to think about), or, in other words, messaging.
As you can see, the person who coined the term "OO" has a rather metaphysical view on objects, Cook has a rather pragmatic view, and Pierce a very rigorous mathematical view. But the important thing is: the philosopher, the pragmatist and the theoretician all agree! Messaging is the one pillar of OO. Period.
In his paper, Cook also looks at OOP from a different angle: Data Abstraction. He clarifies the differences between the two currently most widely-used forms of Data Abstraction, namely Objects and Abstract Data Types. And he notes that the fundamental distinction is that two instances of the same Abstract Data Type can inspect each other's representation, whereas two Objects, even if they are instances of the same type, cannot. He calls this Autognosis (Self-Knowledge, meaning an object only knows itself), although I prefer the term Xenoagnosticism (Foreign-Not-Knowledge), since the important thing is not that an object knows about itself, but rather that it doesn't know about other objects.
So, that's why primitives aren't OO: you do not interact with them by sending messages, and they aren't encapsulated from each other, only from other types. In other words, they are ADTs, not objects.
However, note that there is a second thing in Java, that also fits the latter description: classes! Yes, two instances of the same class can inspect each other's representation! That means, instances of classes are not objects, and classes do not define objects! This seems to be a little counter-intuitive at first, aren't classes all that OO is about? Well, no. OO is about objects, not classes, that's why it's called OO and not CO. And you can have objects in Java: two instances of the same interface can not inspect each other's representation, so instances of interfaces are objects and interfaces describe objects.
Basically, what this means that you cannot use primitives or classes as types, the only thing you can use as types, are interfaces. What does that mean concretely? Where do types occur? It means that fields, static fields, local fields, method parameters, and method return values can only have an interface as their types, and Generic type arguments, the
instanceof operator, and the cast operator can only be used with interfaces as arguments. Or, looking at it from the other side: a class can only be used as a factory, i.e. a class name can only appear directly after the
new operator. (Primitives cannot be used as types, either, obviously.)
There's another aspect of OO that needs mentioning: simulation. OO was born in simulation (Simula, the very first language we would now characterize as OO, was a language designed for simulations), and one of the principles of OO is that all you can observe are the messages you send the object and how the object responds to those messages, as long as two objects behave the same, they are indistinguishable. Or, in other words, an object can simulate another object. Reference equality breaks this, because comparing references allows you to distinguish between two otherwise identically behaving objects, between the simulator and the simulatee, if you will.
So, in closing, the three things that are not OO in Java, are:
And since there are things that are not OO, and even more such important things as classes, without which it is impossible to write any sensible Java program, one might reasonably call Java "impure" with respect to OO.
Note, however, that there is nothing inherently "bad" about being "impure". For example, Object-Oriented Data Abstraction and Data Abstraction using Abstract Data Types have different trade-offs and are complementary, so it is good that you can use both in the same language.
(I must admit I'm less forgiving about primitives, though. The Lisp and Smalltalk communities had solved the problem of high-performance and representation overhead for "primitives" long before Java, and there was even a very high-performance Smalltalk-like VM developed within Sun, namely the Self VM. So, they never were necessary for performance and should never have made it into the language.)