Re: classes question
Mark Thomas wrote:
I think the question that you should be asking yourself is why does one
object *need* access to another object's state. Ideally the object
itself should do all processing that involves its own state - that's
what Thomas was talking about in his first statement. If getters and
setters are needed, it implies that some object is performing processing
involving another object's state, and perhaps indicates that the design
needs refactoring.
public class ImageProcess
{
private float ivRotate = 0.0f;
private File ivFile = null;
public class ImageProcess(File imageFile)
{
super();
ivFile = imageFile;
}
public float getRotate()
{
return ivRotate;
}
/**
* Valid rotate value is between 0.00 and 359.99 inclusive
*/
public void setRotate( float rotate )
{
if ( rotate >= 0.0f && rotate <= 359.99f )
ivRotate = rotate;
}
public rotateImage()
{
....
}
}
Whatever calls setRotate() will certainly change the state of ImageProcess.
Getters & setters are a violation of encapsulation
and should be avoided.
No, the opposite is true. An object encapsulates its information and
what it is doing when it processes that information. Part of the
encapsulation is the protection of its attributes. In the above, if
ivRotate was exposed, then the value of ivRotate could be set to an
illegal value. The setter enforces proper values (and could possibly
throw an exception).
And there is no real speed penalty. The VM analyzes the getter/setter.
If all it is doing is a simple get or set (ie, no processing), then the
VM directly accesses the attribute, without going through a method call.