Page 343 - Introduction to Programming with Java: A Problem Solving Approach

private String name;
private String primary;
private String trim;
// person's name
// shirt's primary color
// shirt's trim color
8.4 Encapsulation (With Instance Variables and Local Variables) 309
private access modifier for each such data item. As you already know, a class’s object-state data
items are called instance variables.
• Second,breakaclass’stasksintoseparatemethods,whereeachmethodholdsasetofadditionalencap-
sulated data it needs to do its job. As you already know, a method’s data items are called local variables.
Declaring instance variables within a class is one form of encapsulation, and declaring local variables within a method is another form of encapsulation. Which is the stronger (more hidden) form of encapsulation? All instance methods have access to all instance variables defined in the same class. On the other hand, only the current method has access to one of its local variables. Therefore, a local variable is more encapsulated than an instance variable. Thus, to promote encapsulation, use local variables, not instance variables, whenever possible.
In writing a method, you’ll often find the need for more data than what’s provided by the current instance variables. The question then becomes—how should you store that data? In another instance variable? Or lo- cally? Try to resist the urge to add another instance variable. You should use instance variables only for stor- ing fundamental attributes of the class’s objects, not for storing additional details. If you can store the data locally, then do so. That furthers the goal of encapsulation. Usually when we think of storing data locally, we think of a local variable declared inside a method’s body. Be aware that parameters are another way to store data locally. Remember that a parameter is declared in a method’s heading—that tells us it has local scope.
Local Variables Versus Instance Variables in The Shirt Class
Now let’s see how the above philosophy plays out in the Shirt class. The fundamental attributes of a shirt are its name, its primary color and its trim color. That’s the basis for our declaration of the three instance variables declared in FiguAre 8p.4a:go PDF Enhancer
Now let’s look at the other variables we need as we write the class’s methods. All of these other vari- ables are somehow associated with the selectColor method in Figure 8.4b. We need to transfer data in both directions between the calling Shirt constructor and the called selectColor method.
First, consider transfer of data into the selectColor method. If a shirt’s primary color is needed, then selectColor should print this prompt message:
Enter shirt's primary color (w, r, b):
If a shirt’s trim color is needed, then selectColor should print this prompt message: Enter shirt's trim color (w, r, b):
We must transfer data into the selectColor method that tells the selectColor method which query to print. It would be possible to transfer this data by declaring another instance variable called colorType, have the Shirt constructor write a value to this instance variable, and then have the selectorColor method read the value of this instance variable. But this would be bad practice because it would break the encapsulation within the selectColor method and add confusing clutter to our nice clean list of object attributes. The proper way to implement this method-to-method communication is the way we did it, with an argument/parameter transfer.
Second, consider transfer of data out of the selectColor method. We also have to transfer data back from the selectColor method to the Shirt constructor. This data is the string representation of the selected color. There are three good ways to transfer data back to the calling method: