By using setters you can prohibit invalid data assignation for your private instance variables thereby protecting your code from malfunctioning. And since you use the private variable, the clients shall get its value using the public getter method.
This way you encapsulate your code -
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.
Gagan Kinra wrote:
but thru getters and setters we care exposing our private instance variable or even class variables to the client code, which itself breaks the security.
I am trying to understand why we need to provide setters and getters for private members ? and also do we provide setters and getters for class variable...if so reason behind it?
You don't have to provide getters and setters for all your member variables. It's better to start off not doing it, and then only expose those that really have a reason to be exposed. I typically start by making my member variables private and final, and either initializing them at declaration (such as for collections) or directly from constructor parameters, or deriving them from constructor parameters and/or other member variables at construction.
Now, when you do decide that there's a reason to expose a particular member variable, there are several reasons to use get/set methods rather than just making it non-private:
You can validate the input, as already shown in this thread.
You can manipulate or transform the input, such as converting a String to an int, or putting a cap on a value, or rounding it.
You can return a calculated value, rather than storing it in a member.
You can defer setting a value until get() is called, possibly preventing unnecessary, expensive calculations.
You can provide a get() but no set(), making the variable publicly readable but not publicly writable.
You can use runtime polymorphism to enable a subclass to have different behavior, such as different validation rules or different calculations.
You can change the implementation without changing any client code. For example, add, remove, or change any of the above, without users of your class having to change their code or even be aware of your change.
You can't do any of the above if you just provide direct access, rather than using get()/set() methods.
Again, though, if you just add plain old pass-through get()/set() to every member variable as a matter of course, you're doing it wrong.
Jeff Verdegan wrote:You don't have to provide getters and setters for all your member variables. It's better to start off not doing it, and then only expose those that really have a reason to be exposed.
@Gagan: And, as you get further along, you'll discover that you often don't want to publicize them (particularly setters). It's usually much better to design your objects to act on messages based on business rules. You may find this article useful.
Isn't it funny how there's always time and money enough to do it WRONG?
Joined: Oct 13, 2005
And you will find objects much easier to handle if you can make them immutable.
Joined: May 14, 2012
Thanks a lot everybody... especially Jeff Verdegan for wonderful explanation..