2. * 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);

3. * 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.

4. * 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.

5. * 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); * }

6. * 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.

7. * 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.

8. * 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; * }

9. * 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; * }

10. * 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.

11. * 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.

12. * Side effects or poorly named methods can be unpleasant. The following example illustrates this: * public int getSeedCount() * { * int temp = seedCount; * seedCount = 0; * return temp; * }

13. * 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.