Java - Using Accessor and Mutator Methods

Java - Using Accessor and Mutator methods

Let's go over the basics:
"Accessor" and "Mutator" are just fancy names fot a getter and a setter.
A getter, "Accessor", returns a class's variable or its value. A setter, "Mutator", sets a class variable pointer or its value.

So first you need to set up a class with some variables to get/set:

public class IDCard
{
private String mName;
private String mFileName;
private int mID;

}

But oh no! If you instantiate this class the default values for these variables will be meaningless.
B.T.W. "instantiate" is a fancy word for doing:

IDCard test = new IDCard();

So - let's set up a default constructor, this is the method being called when you "instantiate" a class.

public IDCard()
{
mName = "";
mFileName = "";
mID = -1;
}

But what if we do know the values we wanna give our variables? So let's make another constructor, one that takes parameters:

public IDCard(String name, int ID, String filename)
{
mName = name;
mID = ID;
mFileName = filename;
}

Wow - this is nice. But stupid. Because we have no way of accessing (=reading) the values of our variables. So let's add a getter, and while we're at it, add a setter as well:

public String getName()
{
return mName;
}

public void setName( String name )
{
mName = name;
}

Nice. Now we can access mName. Add the rest of the accessors and mutators and you're now a certified Java newbie.
Good luck.

No accessor method and mutator method

Accessor methods are often called getters and mutator methods are often called setters.

A widely used pattern within the Java world is that you

  • make your fields (instance variables) private

    private int a;
  • add a getter if you need an accessor method

    public int getA() {
    return this.a;
    }
  • add a setter if you need a mutator method

    public void setA(int a) {
    this.a = a;
    }

Accessor and mutator methods almost always change a single field.

Note that I, just like Aaron Davis, don't like this design either. Since subclasses are only able to add functionality, and are unable to remove or hide it, one must choose wisely which class extends the other. An example would be the well-known squares-rectangles problem.


You also need to use self-descriptive names. a, b and c should be renamed to something better describing what those variables represent.

Why should a method (not) be both accessor and mutator?

Unless runSimulation() is a blocking method and you want to run it asynchronously so it doesn't block your main thread, theres no harm in returning the result with the same method you create the simulation with, as long as returning it can be done cheaply.

Sometimes it is a matter of convenience: is the design of your object such that users will almost always be requesting the result after creating/running the simulation? It might be a good idea, then, to return the result in the mutating method (maybe you could name the method "runSimulationForResult()").

Sometimes it's a matter of efficiency: for some kinds of List implementations (LinkedList, etc.), calling get() followed by set() means the list is traversed twice instead of once, and even though it might not be a super common pattern, the designers decided there wasn't any harm in returning the previous value, since it could be achieved practically for free, and would make certain idioms twice as fast.

Moving accessor and mutator methods from one class into its superclass

You can't put a function call on the left-hand side of an assignment. That just doesn't make sense.

If medication weren't private, you could just have your method assign to it. Since it's private, you can't. There are two solutions:

  1. Change private to protected in the Patient class. This lets child classes access it directly, while outside clients still can't see the medication field.

  2. (my preferred method) Add a setMedication method to the parent (Patient). You could make this protected so that child classes could call setMedication while outside clients could not. In any event, the InPatient class would use that method to set medication (using the syntax super.setMedication(medication) so that it calls the method in the parent class).

Is this method a mutator or accessor method?

None of them. You doesn't mutate any instance and you don't return a field instance either.

Your method makes some logic, so you could say that it is a logic/business method.



Related Topics



Leave a reply



Submit