Tuesday, February 01, 2005

thoughts on setters and getters

Yesterday me and a few of my colleagues had a discussion on the sanctity of getters and setters. I am I.;) I mean when its written I say thats my take on the discussion. Identities are preserved.

P Says:
Some time back I was going through an article where the gist of the topic was

“Not to provide getter and setter methods for manipulating the member variables”.

# The main reason for not doing that is, it’s not following the “Encapsulation” term.
When we are passing the member variable to another invoking object, the data is no longer
Encapsulated as the member variable can be manipulated by the other object, which they feel
Is not the real encapsulation.
What they are proposing is any manipulation of member variable can be done in the same class and
Any methods related to those variables needs to be provided in the same class.

After going through those lines, thoughts started bubbling out, which I can’t keep to my self.
So some doubts and approaches from my side.
# Generally we follow the get and set methods very often.
If we will not do in that way, then what should be the class structure will be.
Incase we need some functionality depending upon some other class variable then how we will do that.

=======================================================================

D Says:
I am not quite sure of your scenario.

What I have seen…

Getters/Setters are used in Java bean or value objects sort of environment.

Ideally, these value objects should only be populated in the constructor for preventing data corruption. But in some scenarios, the value objects gets constructed at one place, gets partly populated at the same place and the rest of the data is set at some part of the code. What to do in this sort of cases?

In case you need some functionality based on some other classes’ variable, you can use a getter….. In this case also, u are not corrupting the data. The problem arises only when you use a setter. I don’t think using a setter outside a bean environment is good.

Any other scenario that you remember???
=======================================================================
N Says:
Encapsulation doesn’t mean hiding data, it means encapsulating the related methods and data. So by putting getter and setter methods Encapsulation is still there. You should write this comment for that article, person who wrote this article must not knowing actual meaning of Encapsulation. But its right that if you provide unnecessarily getter and setter it can be mis-utilized but that is design level consideration. At the time of design one must be careful about what data require getter and setter, these methods can be provided with validation check before actually changing the actual data.

Regarding getting data from one class to other I think there has to be proper interface (can be getter or setter) or some data transfer objects which doesn’t carry full data but the part of data that is required.

===========================================================================
I Say:
If you need to get some data from some other class one should use a pattern (maybe state pattern or something like that. I am not knowledgeable in this). Maybe this is a better method than getter.
============================================================================
D Says:
Why do we need to encapsulate related methods and data?
Is it because we need the data to be manipulated only by those method?
If this is the case, I don’t see why should we expose a setter method as public?
What say?
=============================================================================
N Says:
We don’t have setter method always or for all member variables. Like before rendering you can set rendered object and then perform rendering, so user has flexibility to change the renderer before performing rendering but still logic for rendering is with actual class and it can’t be changed.
============================================================================
I Say:
Encapsulation can lead to data hiding which is a good thing as each class should have a secret (logic for rendering). An logical extension would be to make setters inaccessible from other classes or to say setters are sin (and make them non-public). What say people? Am I confusing issues here?

=========================================================================
D Says:
I am not able to get the meaning of logic for setter methods? Setter methods are supposed to take in a parameter and set the instance data to the passed parameter.

So, if a setter is public, anyone can access that and set its value later on????/
============================================================================
D Says:
One of the advantages of using setter what I found is ….

We can put our logic in setters which we cannot do in constructors….Example, set the variable’s value only if its positive…..

So, even if we use a constructor we should call the setter from there…. Should the constructor be only private then????
==========================================================================

Then some of us met over tea and discussed this phenomenon further.
The conclusions we came to were:
ideally getters should not be there. if data is contained in a class it should be used within a class. a private getter method can be used as an extreme case (to avoid code duplication compared to the case of getter method not being there).
ideally setting of values should be done in constructer. Else it should be done via a private method so that dubplication of code is avoided (same reason as for getters).

What do you all think?

7 Comments:

At 5:01 PM, Blogger suresh said...

I would say there should be no getters/setters (of course, i am talking about the public ones). Reason is: It violates Encapsulation. Why do we need the data of an object. If we give away the data, then why need objects at all. Instead we should ask the object to do that operation that we intended to do with the data. Secondly, data on objects should not be set after the object has been created. If the object cannot be completely created, then we should use some pattern to create the object itself(Builder etc). And encapsulation is all about data hiding, though that is not the only thing about encapsulation. Look at the notes on Encapsulation in Object Bootcamp posts.

 
At 6:48 PM, Anonymous Anonymous said...

Encapsulation and Information Hiding are 2 different concepts that people are always confusing. As said somewhere in the post, Encapsulation is the bundling of data and operations on that data in the same class/module. So, a class that has public variables, or getters/setters, and has methods that operate on that data does not break encapsulation.
Information hiding is concerened with hiding data/data structures from external classes/modules.
Typically you would use Encapsulation and Information Hiding together to build a well designed OO system

 
At 10:55 PM, Anonymous Anonymous said...

The commenter above is correct that encapsulation and information hiding are orthogonal concepts but does not understand encapsulation. It is not the "bundling of data with operations". Encapsulation is enforcing that changes to the state of an object can ONLY be performed through its public API. So an object that has operations and public member variables is not encapsulated.

 
At 6:40 PM, Blogger suresh said...

No, I disagree. When a getter/setter is provided, it means that the data from that object is being used somewhere else. Which means that the behaviour is somewhere else. So it violates encapsulation. Encapsulation is broken even when a behaviour is in a wrong place.

 
At 8:48 PM, Anonymous Anonymous said...

"The concept of encapsulation as used in an object-oriented context is not essentially different from its dictionary definition. It still refers to building a capsule, in the case a conceptual barrier, around some collection of things."
-- [Wirfs-Brock et al, 1990]

 
At 3:11 PM, Blogger partha said...

So if you look at the implementation perspective then how it can be accomplished?
My line of thinking is:
+ In the first place, inter object communication should only follow publicly accessible method invocation.
+ Due measures needs to be taken to make sure not to spill out the member variables out of the class.
+ In case some other entity needs other class’s member variable to implement some functionality, then the
Functionality needs to be implemented in the class where the targeted member variable resides rather than in the
Class which is in need of the variable.
By doing this, equilibrium is established between different entities in ENCAPSULATION perspective.

Comments on this are highly appreciated.

 
At 3:14 PM, Blogger partha said...

So if you look at the implementation perspective then how it can be accomplished?
My line of thinking is:
+ In the first place, inter object communication should only follow publicly accessible method invocation.
+ Due measures needs to be taken to make sure not to spill out the member variables out of the class.
+ In case some other entity needs other class’s member variable to implement some functionality, then the
Functionality needs to be implemented in the class where the targeted member variable resides rather than in the
Class which is in need of the variable.
By doing this, equilibrium is established between different entities in ENCAPSULATION perspective.

Comments on this are highly appreciated.

 

Post a Comment

<< Home