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

310 Chapter 8 Software Engineering
1. If there is only a single return value, you can send it back to the calling module as a return value.
2. If there is more than one value to return, you can assemble these values into an object, create that object
in the helper method, and return a reference to that locally created “communication object.”
3. You can pass into the helper method references to “communication objects” instantiated in the calling
module and use code in the helper method to write to those objects.
It’s also possible to transfer data back to the calling module by declaring other instance variables, having the helper method write values to them, and having the calling module read from them after the helper method terminates its execution. But this would be bad practice, because it would break the encapsulation 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 a return value. In this case, the return value is a reference to a String object.
The Shirt class has one other variable to consider, the stdIn reference to a keyboard communication object. This particular object is used by both the calling constructor and the called helper method, and it is instantiated twice, once in each of those two modules. It is tempting to try to avoid duplicate instantiation by making stdIn an instance variable. And it will “work.” But we recommend against it, because stdIn is clearly not a fundamental attribute of this class’s objects. It’s not a variable that describes the state of a shirt! In a later version of the program, you might want to change the method of input from the keyboard to something else, like a data file, described later in Chapter 15. You might even want to use one method of input for the name and a different method of input for the other state variables. Then you’d need to change stdIn, and you might want to change it in different ways for different methods. Declaring it local makes future modifications local also, and it’s better design practice.
An argument used for not making a variable local is “maybe someday we’ll need broader scope.” If you
Apago PDF Enhancer
have a specific plan that truly requires the broader scope you propose, OK. But if it’s just “maybe someday,” don’t provide broader scope until that “someday” actually comes. Then, at that time, modify your program to increase scope only where it’s absolutely necessary.
8.5 Design Philosophy
In the next several sections, we discuss alternative strategies for solving problems. That’s plural “strategies” because there’s not just one cookie-cutter strategy that can be used to solve all problems. If there were just one universal strategy, programming would be easy and anyone could do it. But it’s not easy. That’s why good programmers are in demand and earn a decent wage.
Simplistic Approach to Design
Here’s a simplistic recipe for how to design things:
1. Figure out what you want to do. 2. Figure out how to do it.
3. Do it.
4. Test it.
At first this list seems like obvious common sense. But actually, it works only for very simple problems— problems where everything is easy and you don’t need any recipe. What’s wrong with this recipe?
First, if a problem is difficult, it’s hard to know what its solution will be like. Often we need experience to know even what we want to do. Most clients recognize this and are flexible enough to accept a range of possible