Principle: Don’t Repeat Yourself (DRY).
Every concept must have a single, authoritative representation within a system. Reduce repetition of concepts that are likely to change by replacing them with reusable abstractions.
Section 8.3 Methods
static modifier because we want them to be created within the scope of each object, not the class. This gives the method access to the object instance itself through the this keyword and other items declared in the object, including those with private visibility. We need access to the object in order to effectively manage its internal state.Subsection 8.3.1 Object Methods
We introduced methods in Section 3.2. The difference between what was described there and the figure below is that here we leave out the
static modifier so as to define the method within the scope of the object. Otherwise, the same rules apply.
As an example, let’s add three methods to our LED class that turn the LED on, turn it off, and return the current state of the LED. Turning on an LED object sets the internal
on variable to true and changes the managed Oval fill color to red. Turning it off resets the on variable to false and the Oval fill color back to dark gray. Obtaining the state of the LED simply returns the value of the private on instance variable. We’ll call these methods turnOn(), turnOff(), and isOn(). None of these new methods happen to take parameters.
Listing 8.3.2 shows the code changes to our class definition. The added
turnOn() and turnOff() methods do what we expect, setting and configuring the state of the object by modifying its private instance variables. The isOn() method returns the boolean value of the on instance variable. Because we have abstracted the concept of the LED being off and on and exposed this behavior as new methods, it is wise to remove the initial explicit instance variable configuration statements from the constructor that starts the LED in the off state and replace them by invoking the turnOff() method directly. This way, should turnOff() be modified later to do more than its current definition, we can feel confident that making the update in one place will apply whenever the LED is turned off.Consider what might happen if we continued to initialize the instance variables directly in the LED object’s constructor and also modify the instance variables in its methods. Doing this requires us to make sure that the constructor and the
turnOff() method remains consistent. If we decided to change the fill color of the LED when off, and we modified the code in turnOff() but forgot to make the comparable changes to the constructor, we would end up with an inconsistency in our object. The ramifications of making this mistake in this example are minor. But one can imagine how such a similar oversight can lead to more serious problems. This important software development principle has been dubbed Don’t repeat yourself or DRY.To test our new methods, in addition to replacing configuration statements in the constructor with
turnOff(), we invoke turnOn() in main(…) on both LED objects after instantiation. We also test the state of the first LED object by invoking its isOn() method and printing the result. See the result in Figure 8.3.3.// LED.java (version 4)
// A simple LED display class
import doodlepad.*;
public class LED {
private boolean on; // Tracks state of LED object
private Oval light; // Visual display of object
// Constructor
public LED(double x, double y) {
this.light = new Oval(x, y, 30, 30);
this.turnOff(); // Init state by invoking method (**NEW**)
}
// Turn on LED (**NEW**)
public void turnOn() {
this.on = true;
this.light.setFillColor(255, 0, 0);
}
// Turn off LED (**NEW**)
public void turnOff() {
this.on = false;
this.light.setFillColor(100, 100, 100);
}
// Return state of LED (**NEW**)
public boolean isOn() {
return this.on;
}
// --- Test LED
public static void main(String[] args) {
// Create LED objects
LED led1 = new LED(100, 100);
LED led2 = new LED(200, 100);
// Turn on both LED objects (**NEW**)
led1.turnOn();
led2.turnOn();
System.out.println( "LED1 is" + (led1.isOn() ? "" : " not") + " on");
}
}
LED.java (version 4)javac -cp doodlepad.jar LED.java java -cp .;doodlepad.jar LED LED1 is on
LED.java (version 4)Subsection 8.3.2 Accessor and Mutator Methods
Encapsulation requires that we manage access to instance variables. We can make an instance variable accessible simply by declaring it with public visibility. This leaves the variable’s value wide open to change by any part of our program. Consequently, we also lose the ability to manage it, such as by restricting its value to a valid range.
The standard way to manage instance variable values is to declare them with private visibility, and add methods that are used to set the value of each instance variable as well as to get the value of each instance variable. A method designed to set the value of an instance variable is called a mutator method, also known as a setter. A method designed to get and return the value of an instance variable is called an accessor method, also known as a getter. By convention, typically we name these methods by prepending the instance variable named with set in the case of a mutator method (setters), and get in the case of an accessor method (getters).
By defining mutator methods and accessor methods for an instance variable, we open up a wide range of options for managing their values. For example, if we want to restict the value of an
age instance variable to a number greater-than or equal-to 0.0, we could test the value before assigning it in a mutator method. The following setAge(…) mutator method is a simple example.As another example, consider that we can configure an instance variable to be read-only simply by defining a getter method but not a corresponding setter method. Without a setter, we can never change the instance variable value, only read it.
Let’s expand our LED class once more. Let’s assume that we can choose the color that the LED emits when it is on to one of four values: RED, GREEN, BLUE, and YELLOW. It is easy enough to add an instance variable that holds an LED color, but we also need to manage that variable, limiting it to one of the four possible values. To manage this instance variable, we must add to the LED class a
setColor(…) method, a setter, and a getColor() method, a getter. To help with this addition, let’s define an enum with constants for the four LED colors, similar to what we did in Section 2.7.enum LEDColor { RED, GREEN, BLUE, YELLOW };
To incorporate this option into our LED class, we made the following changes. Refer to Listing 8.3.4.
- Added the enum to the bottom of our LED.java file.
- Added a private scoped
LEDColor colorinstance variable to hold an enum constant. - Added
setColor(…)method to the class that takes the LEDColor enum constant as a parameter. This limits values to one of the four color constants. - Added a
getColor()method to the class that returns an LEDColor enum constant. - Initialized the
colorinstance variable in the LED constructor - Added a
switchstatement to theturnOn()method that sets color based on the value ofcolorinstance variable.
// LED.java (version 5)
// A simple LED display class
import doodlepad.*;
public class LED {
private boolean on; // Tracks state of LED object
private Oval light; // Visual display of object
private LEDColor color; // LED Color (**NEW**)
// Constructor
public LED(double x, double y) {
this.light = new Oval(x, y, 30, 30);
this.turnOff(); // Init state
this.color = LEDColor.RED; // Default to RED (**NEW**)
}
// Turn on LED
public void turnOn() {
this.on = true;
switch (this.color) { // Set selected color (**NEW**)
case RED:
this.light.setFillColor(255, 0, 0);
break;
case GREEN:
this.light.setFillColor(0, 255, 0);
break;
case BLUE:
this.light.setFillColor(0, 0, 255);
break;
case YELLOW:
this.light.setFillColor(255, 255, 0);
break;
}
}
// Turn off LED
public void turnOff() {
this.on = false;
this.light.setFillColor(100, 100, 100);
}
// Return state of LED
public boolean isOn() {
return this.on;
}
// MUTATOR method for LED Color (**NEW**)
public void setColor(LEDColor color) {
this.color = color;
}
// ACCESSOR method for LED Color (**NEW**)
public LEDColor getColor() {
return this.color;
}
// --- Test LED
public static void main(String[] args) {
// Create LED objects
LED led1 = new LED(100, 100);
LED led2 = new LED(200, 100);
// Change LED colors (**NEW**)
led1.setColor(LEDColor.BLUE);
led2.setColor(LEDColor.YELLOW);
// Turn on both LED objects
led1.turnOn();
led2.turnOn();
System.out.println( "LED1 is" + (led1.isOn() ? "" : " not") + " on");
}
}
// Enum for LED Color constants (**NEW**)
enum LEDColor { RED, GREEN, BLUE, YELLOW };
LED.java (version 5)javac -cp doodlepad.jar LED.java java -cp .;doodlepad.jar LED LED1 is on
LED.java (version 5)Subsection 8.3.3 Method Overloading
When your source code invokes a method, the Java compiler binds the method invocation with a method implementation. This way, when your program runs, the proper method is executed. This task of binding an invocation to an implementation considers more than just the name of the method. The match is performed on the entire method signature. A method signature is composed of the method name and its parameter list, including parameter type and order.
Matching on the entire signature, and not just the method name, lets us define multiple methods having the same name, as long as the signatures are distinct. This is called method overloading. In a sense, the method name is given multiple meanings, and so the method is overloaded.
A class constructor may be overloaded as well. Multiple constructors may exist in a class provided the signatures are distinct. Overloading a method or constructor gives us the ability to abstract a single concept using one name, but permitting the user to invoke different implementations by passing different parameter values.
A good application of method overloading is to use it as a way to set default parameter values for a method or constructor. Consider the
setFillColor(…) method of all DoodlePad shape objects. As we know, this method can take the three color components: red, green, and blue, and that is the way we’ve used it. But in fact, there are several other options (overloads) for invoking setFillColor(…).Colors in DoodlePad may be partially or fully transparent. This is set using a fourth value in the range [0, 255] known as opacity, and is designated using the variable alpha. An alpha of 0 means fully transparent and an alpha of 255 means fully opaque. All color-related DoodlePad methods can take four color component parameters, the fourth being transparency specified as alpha. If that fourth parameter is omitted, DoodlePad substitutes an alpha of 255, fully opaque. This is implemented by overloading the definition of
setFillColor(…), which you can observe in the DoodlePad source code 1 . The three-parameter overload of setFillColor(…) just invokes the four-parameter overload with 255 passed as the alpha value./**
* Set the fill color with which to draw the shape
* @param red the red component of the color [0, 255]
* @param green the green component of the color [0, 255]
* @param blue the blue component of the color [0, 255]
*/
public void setFillColor(double red, double green, double blue) {
setFillColor( red, green, blue, 255 ); // Default alpha to 255
}
All shades of gray in the RGB color model are formed by setting the red, green, and blue color components to the same value in [0, 255]. DoodlePad provides an overload that repeats the first value three times when only one parameter is provided. See the following additional overload. The DoodlePad source code 2 is an interesting repository to explore to see applications of many of the principles that we study in this book.
/**
* Set the gray scale fill color with which to draw the shape.
* @param gray the gray scale value in the range [0, 255]
*/
public void setFillColor(double gray) {
this.setFillColor(gray, gray, gray, 255);
}
Constructors may be overloaded as well. The Java compiler matches and binds the invoked constructor signature to available constructor definition signatures to ensure the proper constructor implementation is invoked.
As an example, rather than defaulting the LED color to RED and then changing it using the
setColor(…) method, let’s overload the constructor with two implementations. The more general implementation takes the LED "on" color as a third parameter, and a two-parameter overload invokes the three parameter implementation with the value LEDColor.RED as the third parameter, making it the default. Note that a constructor overload is invoked using this as the scope instead of the class name, and no new keyword.// Overloaded constructor defaults color to RED
public LED(double x, double y) {
// Invoke alternative constructor with RED as default
this(x, y, LEDColor.RED);
}
// Main constructor expects color constant as a parameter
public LED(double x, double y, LEDColor color) {
this.light = new Oval(x, y, 30, 30);
this.setColor(color); // Set LED on color
this.turnOff(); // Init state
}
It is common practice in Java to define one method or constructor with the most general implementation, and then one or more overloads that provide default parameter values. This practice is also a good example of DRY.
Subsection 8.3.4 The toString() Method
One special method of a custom class that you may define has the signature
toString() and returns a String type. The purpose of this method is to construct and return a String representation of the object. The toString() method is invoked whenever an object is printed using the System.out.println(…) and similar methods.To the program in Listing 8.3.4 let’s add the following method.
// String representation of an LED object
public String toString() {
return "LED is" + (this.isOn() ? "" : " not") + " on";
}
toString() method for LEDThis method returns a String representing the LED, which also indicates of the current LED object is on or off. It is the same String printed at the end of the
main(…) method in Listing 8.3.4. As a result, we can now replace the String.out.println(…) method with one that prints the led1 object directly. See the following edit, which produces the same result as in Listing 8.3.4.//System.out.println( "LED1 is" + (led1.isOn() ? "" : " not") + " on");
System.out.println( led1 );
github.com/russomf/doodlepad/blob/master/src/doodlepad/Shape.javagithub.com/russomf/doodlepad/blob/master/src/doodlepad/Shape.java
