*8.3 Accessor Methods, Mutator Methods, and Side Effects

*Calls to Methods

*Calls to methods may have implicit parameters.

*Explicit parameters may not be needed because the method has the implicit parameter to work with.

*Ignoring the possibility of a return value for the moment, the model for such calls is:

*object.method(parameter(s) optional);

*Different types of method calls

*Methods that can be called on objects generally fall into one of two categories: accessor, or get methods, and mutator, or set methods.

*Accessor methods, in their simplest form, are typed and return the value of an instance variable of an object.

*Mutator methods, in their simplest form, are void, take a parameter, and change the value of an instance variable of an object.

*Accessor vs Mutator Methods

*Both accessor and mutator methods can be somewhat more complicated.

*An accessor may return a value derived from a calculation based on the values of instance variables.

*A mutator may take more than one parameter, and the change to the value of an instance variable may be based on those parameters.

*Example of a complicated

method

*Here is an example of how methods start to get more complicated.

*public void exchangeSeedCounts(Cup5 anotherCup)*{* int tempThis = this.getSeedCount();* int tempThat = anotherCup.getSeedCount();* this.setSeedCount(tempThat);* anotherCup.setSeedCount(tempThis);*}

*Example of a complicated

method

*With respect to the implicit parameter, this is a mutator method.

*It takes a parameter and the value of an instance variable of the implicit parameter is changed.

*However, the explicit parameter is an object reference and is also changed by the call.

*Even though the explicit parameter is changed, it would not be correct to refer to this method as a mutator of the explicit parameter.

*Accessor and mutator refer to the effect of the method on the object that the method is called on.

*Side Effects

*The change to the implicit parameter allows us to classify this method as a mutator, but this effect is not the only effect of the method.

*The secondary effect is the change to the explicit parameter.

*This additional effect is known as a side effect.

*If a method has a side effect, it is desirable that the method name somehow indicate that, as the name of this method does, so that programmers understand fully what the method does.

*If it is possible to avoid side effects altogether in the methods of a class, that is not a bad design decision.

*Naming convention and design decisions

*Consider the method shown below.

*Its name says that it increases seedCount, but if the value of addedNumber passed into the method were negative, the reality is that the value of seedCount would be decreased.

*You might argue that the method is poorly named.

*It might be better to call it something like changeSeedCount(), although that is kind of ambiguous.* public boolean increaseSeedCount(int addedNumber)* {* seedCount = seedCount + addedNumber;* return true;* }

*Naming convention and design decisions,

cont.

*Continuing from the previous example, consider the increaseSeedCount() method shown below.

*public boolean increaseSeedCount(int addedNumber)*{* if(addedNumber > 0)* {* seedCount = seedCount + addedNumber;* return true;* }* else* return false;*}

*Naming convention and design

decisions, cont.

*It is a mutator with respect to the implicit parameter.

*The body of the method includes a condition which makes the name of the method, “increaseSeedCount” literally true.

*If the addedNumber parameter passed to the method is not positive, then its value is not added to the seedCount

*The method returns a boolean value signaling whether the value was added or not.

*Naming convention and

design decisions, cont.

*In a sense, the conditional execution of the addition and the return of the boolean value could be viewed as side effects.

*These side effects are valuable.

*The conditional execution makes the name of the method literally true, and the boolean value informs the calling program of what happened when the method was called.

*Bad side effects and poorly named

methods

*Side effects or poorly named methods can be unpleasant. The following example illustrates this:

*public int getSeedCount()*{* int temp = seedCount;* seedCount = 0;* return temp;*}

*Bad side effects and poorly named

methods

*This method takes the meaning of “get” literally.

*It retrieves the seedCount, leaving nothing behind.

*However, it is unlikely that such an outcome would be expected or desired.

*At the very least the method should be named in such a way that its action is clear.

*Something like zeroOutSeedCount() would be more descriptive.

*Since the same result can be accomplished by a call to a normal getSeedCount() method followed by a call to setSeedCount() with a parameter of 0, a method such as this one is probably not needed.