File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes Help? Odd Behaviour of Mutator methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Help? Odd Behaviour of Mutator methods" Watch "Help? Odd Behaviour of Mutator methods" New topic

Help? Odd Behaviour of Mutator methods

Sarah Jacob

Joined: Jul 30, 2001
Posts: 7
If x is a private member of a class,then
public class setX(double inputX)
x = inputX;
can alter the value of this private x.I could just make it public.I just read that the advantage of using a method in this way is that you can apply validity checks on the new value that is to be set. I don't quite understand this concept.Can anyone explain this above line.
Thanks in advance,
William Barnes
Ranch Hand

Joined: Mar 16, 2001
Posts: 986

(No idea what mutator means.)
The reason you would want an accessor method (a method that sets or gets values for private data members) is to keep that private/public thing going.
Yes, if you declare "x" as public anyone would be able to change it's value. But than "anyone would be able to change it's value". You see the problem. Using the logic that everything is public we could just write one large class to do everything (that used a lot of gotos).
You want to break things down into classes, and than establish relationships between the classes. That whole OO thing. The public/protected/private attributes help with that.
So lets have a really simple example. You have a class for "car". The car class has a private data member of "gas milage". There is a accessor method to set the gas milage for the car called "setGasMilage". Now within that method you can check for realistic values before setting the gas milage. So if someone tries to tell your class that their SUV (really big car) gets 40 miles to the gallon, you can tell them to go buy a Civic (small car good milage).

Something like that.

Please ignore post, I have no idea what I am talking about.
Sarah Jacob

Joined: Jul 30, 2001
Posts: 7
Thanks Christopher for the explanation.So,what this really means is the value of gasMilage can be changed by another class (say)Person which might call setGasMilage...whether this Person class is in the same package or a different package....
FYI according to Ivor Horton's book ...getX() methods are Accessor methods and setX() methods are Mutator methods..
public class car
private int gasMilage ;
public setGasMilage( int X) throws GetRealException
if( X > 35)
throw new GetRealException() ;
gasMilage = X ;
Colin Kenworthy
Ranch Hand

Joined: Aug 06, 2001
Posts: 88
An 'accessor' method is simply a 'get' method - a method you call to access some value(s) in an object.
A 'mutator' on the other hand is simply the opposite of an 'accessor' method, i.e. a 'set' method, it allows you to mutate or change the contents of an object.
If you allowed x to be public then any class would be able to read or alter the value of x, and you would be exposing the implementation of the object. For example it may be that x is a temperature that is held as a float in the class. The class may implement the temperature within itself as the number of degrees above absolute zero. Now what would happen if another class set this to a negative value ? How could the object prevent itself from having nonsense values placed inside it ? What would happen if we decided to re-write this class so that the temperature was held as degrees centigrade - we would have to go looking through all our other classes to find any that set the temperature x. We lose all the advantage of OO and give ourselves the headache of traditional procedural programming.
Now by making x private we hide it from all other classes and we provide methods to set and get the temperature e.g. public float getXFarenheit(); or public boolean setX(float centigrade);. This is known as encapsulation. So, as Christopher says, within these methods we can do any amount of checking and conversion we like and hide the details of how x is actually implemented in our class. Also, since every other class has to use these methods to get at the temperature we only have to change one class if we change the implementation of x (providing we still use float as the parameter and return type).
If you look at the API doc in the documents part of the JDK you will see very few of the Sun supplied objects (class Point is one) let you see how they hold data internally, almost everything is accessed through method calls, e.g. class Vector has a method size() to return an int representing the number of objects contained in the Vector. This is good practice.
Hope this helps...
I agree. Here's the link:
subject: Help? Odd Behaviour of Mutator methods
It's not a secret anymore!