Methods to access objects?

[Derek White]

I have noticed a fair amount of classes use such code:

private String str;
public void setStr(String str)
{
	this.str = str;
}
public String getStr()
{
	return this.str;
}

Is this preferred over making "str" publicly accessible?
If so, please explain why..

[ahalya priya]

Hi
In java to implement encapulations, all variables are declared private and methods those set and get value of particular variables are declared public. So that all other are not able to access that variables directly.

I hope you understand....

[Derek White]

I don't understand why it is unsafe for the member to be accessed directly..

Is there some documentation for this?

[David Newton]

Nutshell version: encapsulation.

Getters and setters allow additional functionality to be included--as a trivial example think of lazy instantiation of expensive properties. By encapsulating property access behind methods no code needs to change if, say, a publicly-accessible property now needs additional functionality provided by a getter/setter method.

They also allow trivial discovery by tools of properties *meant* to be accessible (by looking for methods prefixed with get/set).

[Gregg Bolinger]

Derek White wrote:I don't understand why it is unsafe for the member to be accessed directly..

Is there some documentation for this?

It's not always unsafe and will depend on your implementation. There's the camp that believes that business logic belongs within the JavaBean. If that is the case, often times when setting or getting a property, business rules must be applied to them first. So there is additional logic in these mutator methods to achieve this. The other reason getters/setters are fairly common is because of libraries that work off JavaBeans and reflection like Hibernate, for example. Hibernate requires getters and setters for every persistent property of the object to work. This is also true many other libraries out in the java world.

There is actually quite a bit of debate regarding private/public variables and mutator methods. Googling and searching this site will provide more information. Unfortunately there isn't really a best practice. More often than not you are going to find yourself requiring getters/setters for various reasons.

[Derek White]

Additional functionality? As in restrictions and such?

private String str;
public void setStr(String str)
{
	if(str.Contains("#"))
		str = str.Replace("#", "");
	this.str = str;
}
public String getStr()
{
	return this.str;
}

Or maybe to fire an event when the String in question is changed?

[Gregg Bolinger]

Derek White wrote:Additional functionality? As in restrictions and such?

private String str;
public void setStr(String str)
{
	if(str.Contains("#"))
		str = str.Replace("#", "");
	this.str = str;
}
public String getStr()
{
	return this.str;
}

Or maybe to fire an event when the String in question is changed?

Yep. You got it. Also note that is can also depend on what you are developing for. When designing a system where a lot of people will be using it and programming against your API it is really important to restrict access and control access to important data. Whether that restriction rests solely on the objects themselves or are proxied through other objects is up to you. But if you need to be concerned about how a property is set (and at times retrieved) from an object, you need to control that via methods, and not expose the variables directly.

It might also be helpful to read the JavaBean specification.

[Derek White]

Thank you very much!

It's something I've always wondered about and now I finally understand .

[arulk pillai]

This will also prevent a varible getting changed with an invalid value. For example, you can check for null or zero, etc prior to assigning if you use encapsulation.

[Gregg Bolinger]

arulk pillai wrote:This will also prevent a varible getting changed with an invalid value. For example, you can check for null or zero, etc prior to assigning if you use encapsulation.

Yea, I think we covered that, but thanks.