This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Others are able to manipulate the instance variable doesnt mean that it is breaking the rule of encapsulation . Others are able to do it , because you have made your function like that. For instance, you can create the clone of the object that you are passing to the setter method and can take the decision. In that case the other world cant do anything with it. Its just act as a handler rather we can say so.
I guess the concept of encapsulation is wrongly interpreted by you...... what exactly is the point is we encapsulate all things in a class....and only things that is available is the APIs by which various objects interact. This gives in the loose coupling concept. Also if you say your code can set the instance variable directly and a new class is shipped to you and now your code will break because now the new class doesn't allow access to the instance variables. We encapsulate in the blueprint(class) so that when the JVM comes across the new keyword it uses the particular class that is loaded in the JVM to create the object.
[ SCJP 6.0 - 90% ] , JSP, Servlets and Learning EJB.
Try out the programs using a TextEditor. Textpad - Java 6 api
By encapsulation, we mean nothing more than associating properties and behaviours to a particular object so that it can be modelled to the real world concept.
Eg: A Vehicle has properties as currentSpeed, MAX_SPEED, power, numOfTyres etc. and behaviours as get/setCurrentSpeed, getMaxSpeed, get/setPower etc. Here we just associated these properties and behaviours to the object Vehicle. That's encapsulation. These are encapsulated/covered/boxed/contained/comprised in that object. In Java these objects are called classes.
Encapsulation has nothing to do with security by default, it's about characteristizing. You made the methods public, that was your choice.
Encapsulation is like the gears in a car,
you can turn the lever forward or backward and affect the working of the car,
but that does not mean you can rotate it (depends on your strength too , dedication can make you do the impossible ).
it also does not mean you can grind the lever way out of its position.
you can move it freely in the space it provides you to without you worring about its internal working and how the
piston is affected
Encapsuation is more than just grouping a set of properties and methods together. It is doing this and then putting a name on it. And that name carries a purpose.
I can create an array of variables. In some languages those can even refer to functions so I can perform operations with it. I could say, "Hey I've got it all encapsulated in this array" But that doesn't cut it, because it keeps being an array.
When you put properties and methods together in a class. That whole package gets delivered as type. So you can distinguish between two methods who's names are the same, but take on different parameters and thus operate different. It would be kinda hard to do if everything were arrays of public things.
Then add different configurations. For example private constructors, abstract methods, static methods, etc. You can create some very interesting classes that will behave just like you want them. If you use interfaces then you can ensure your class complies to a set of rules that allow it to perform as needed. If everything were an adhoc bundle of properties and methods you couldn't really be sure if that "super array" will work when passed to method X. Did you implement all the methods, does it have what it needs to do its job.
Encapsulation goes beyond putting two integers and a string together. I don't see encapsulation as "keeping all members together in an object". It is more like putting a name to a concept (class name) and then modeling it through properties and methods. A class called Egg with two strings and three integers is not the same as a class Seed with two strings and three integers. Even when they share the same number and type of properties.
Joined: Oct 13, 2005
Campbell Ritchie wrote:Please read the important administrative private message I just sent, "Kiran Kb".
You appear not to have read that message. Please find it and take action immediately.