Calls to methods may have implicit parameters Explicit

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

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

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

* Here is an example of how methods start to get more complicated. * public void exchange. Seed. Counts(Cup 5 another. Cup) *{ * int temp. This = this. get. Seed. Count(); * int temp. That = another. Cup. get. Seed. Count(); * this. set. Seed. Count(temp. That); * another. Cup. set. Seed. Count(temp. This); *} *

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

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

*Consider the method shown below. *Its name says that it increases seed. Count, but if the value of added. Number passed into the method were negative, the reality is that the value of seed. Count would be decreased. *You might argue that the method is poorly named. *It might be better to call it something like change. Seed. Count(), although that is kind of ambiguous. * public boolean increase. Seed. Count(int added. Number) *{ * seed. Count = seed. Count + added. Number; * return true; *} *

* Continuing from the previous example, consider the increase. Seed. Count() method shown below. *public boolean increase. Seed. Count(int added. Number) *{ * if(added. Number > 0) * { * seed. Count = seed. Count + added. Number; * return true; * } * else * return false; *} *

*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, “increase. Seed. Count” literally true. *If the added. Number parameter passed to the method is not positive, then its value is not added to the seed. Count *The method returns a boolean value signaling whether the value was added or not. *

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

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

*This method takes the meaning of “get” literally. *It retrieves the seed. Count, 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 zero. Out. Seed. Count() would be more descriptive. *Since the same result can be accomplished by a call to a normal get. Seed. Count() method followed by a call to set. Seed. Count() with a parameter of 0, a method such as this one is probably not needed. *