Abstraction and Encapsulation i.e basic oops concepts gist and their unders

Question

I have gone to many sites and everywhere got some difference in defintion of abstraction and encapsulation.
Below i tried to summarize the findings of both and have some questions which are inline with understanding.
Encapsulation:-
Hiding internal state and requiring all interaction to be performed through an object's methods is known
as data encapsulation — a fundamental principle of object-oriented programming.
Encapsulation is the technique of making the fields in a class private and providing access to the fields via public methods. If a field is declared private, it cannot be accessed by anyone outside the class, thereby hiding the fields within the class. For this reason, encapsulation is also referred to as data hiding.
Question1:- Agreed that we are hiding the instance variable details but again we do expose them with getter and setter
methods. Is it not the violation of encapsulation? What advantage it provides exposing the internal state thru methods
(like getter and setter) but not declaring stae with public modifier.?
Question2:- If class does not have any state variable and has some just simple methods printing hello world.
Can we still say it is encapsulation?
Abstraction:-Abstraction in Java allows the user to hide non-essential details relevant to user.
Question1:- so we can say Encapsulation is also a feature of abstraction because in ecapsulation also we hide data(state) of object. Right?
Question2:-Say a class has 10 methods . Out of these 10 , only two are exposed for outside world with public modifier.Can we say this is the example of abstraction?
Question3:- Can we say interface/abstract class are the baset examples of abstraction as they just expose the masic details i.e signature of method to outside world?

Answer 1

JavaFunda wrote:
Hi jverd whats your take on original post?Question1:- Agreed that we are hiding the instance variable details but again we do expose them with getter and setter
methods. Is it not the violation of encapsulation? What advantage it provides exposing the internal state thru methods
(like getter and setter) but not declaring stae with public modifier.?
>
I don't think you can say whether an individual get/set "violates encapsulation" without more context. If you're just blindly providing direct get/set for every member variable, then it's likely you don't understand encapsulation. There's still some encapsulation there, however, because the caller can't directly see or modify the state.
Sure, a programmer familiar with coding conventions and possessing some common sense could infer that those get/set methods correspond directly to member variables of the same names, but so what? He still has to go through the methods to see or modify the state, and there could be other stuff going on there. The fact that going through the method makes it a black box to him is why I say there's some level of encapsulation. There's a continuum of how "direct" the access to the internal state is, and I don't think there's a clear delineation between "encapsulated" and "not encapsulated."
For example:
As direct as can be: setX() is simply this.x = x and getX() is simply return x.
Somewhat less direct: getFullName() returns firstname + " " + lastName. There's no member variable called "fullName", and the result is composed by operating on multiple pieces of the object's state.
Still less direct: ArrayList's toString() is "[", followed by the results of each of its elements' toString() methods, separated by commas, followed by "]"
Very indirect: Map.put(). We know that it modifies the state of the Map by adding the key/value pair we specify, and we can infer some things about how it's implemented based on the type of Map. But that abstraction is so far separated from the specific state that represents it, that we would probably say that there's a high level of encapsulation there.
And of course there are other scenarios in between these, and further toward the "encapsulated" end of the spectrum than the Map example. Where do you draw the line between "not encapsulated" and "encapsulated"?
I think a reasonable criterion to use is whether the exposed stated has been exposed because it's a natural part of the behavior of the class.
For instance, Colleciton.size(). It makes sense that as part of a Colleciton's behavior, you'd want it to be able to tell you how many items it holds. In an ArrayList, you would probably have a size variable that gets updated each time an element is added or removed. However, in a ConcurrentSkipListSet, there is no size variable. You have to traverse the Set and count the elements. So is size encapsulated here? Is it in one but not the other? Why? I would say it is in both cases, because part of the natural behavior of a Collection is to tell us its size, so the fact that in some collections that can be done simply be returning the value of a member variable doesn't "violate" encapsulation.
But, after having said all that, my real answer is: I don't care. The answer to "Do get/set violate encapsulation?" doesn't matter to me in the least in how I write my code.
>
Question2:- If class does not have any state variable and has some just simple methods printing hello world.
Can we still say it is encapsulation?
>
I would say no, since there's no state to be encapsulated. However, I supposed one could say that the behavior is encapsulated. It could be implemented any number of different ways, some of which would involve state and some wouldn't, and all we'd see is the public interface and the behavior it provides. I don't know that anybody actual does view it that way though.
And, again, this sort of nitpickery is not actually relevant to anything, IMHO.
>
Question1:- so we can say Encapsulation is also a feature of abstraction because in ecapsulation also we hide data(state) of object. Right?
>
More silly semantics. I wouldn't say that encapsulation is a "feature" of abstraction. I think the two often work together, and there's some overlap in their definitions, or at least in how they're realized in code. (Which can be seen in my long-winded answer to the first quetsion.)
>
Question2:-Say a class has 10 methods . Out of these 10 , only two are exposed for outside world with public modifier.Can we say this is the example of abstraction?
>
Don't know, don't care.
>
Question3:- Can we say interface/abstract class are the baset examples of abstraction as they just expose the masic details i.e signature of method to outside world?
>
No idea what you're saying here, but I expect my answer will again be: "don't know, don't care".
Edited by: jverd on Aug 3, 2011 10:22 AM
Edited by: jverd on Aug 3, 2011 10:22 AM