10: Putting Variables and Methods Where They Belong in Java

Generation Code 39 Extended in Java 10: Putting Variables and Methods Where They Belong

It makes no sense to put tally variables in either of the displaying classes (TeamFrame and ShowTeamFrame) After all, the tally has something or other to do with players, teams, and baseball The displaying classes are about creating windows, not about playing baseball You re uncomfortable putting an overall team average in an instance of the Player class because an instance of the Player class represents just one player on the team What business does a single player have storing overall team data Sure, you could make the code work, but it wouldn t be an elegant solution to the problem Finally, you discover the keyword static Anything that s declared to be static belongs to the whole class, not to any particular instance of the class When you create the static variable, totalOfAverages, you create just one copy of the variable This copy stays with the entire Players class No matter how many instances of the Player class you create one, nine, or none you have just one totalOfAverages variable And, while you re at it, you create other static variables (playerCount and decFormat) and static methods (findTeamAverage and findTeamAverageString) To see what I mean, look at Figure 10-5

Going along with your passion for subclasses, you put code for team-wide tallies in a subclass of the Player class The code is shown in Listing 10-4

Listing 10-4:

import javatextDecimalFormat; class PlayerPlus extends Player { private static int playerCount = 0; private static double totalOfAverages = 000;

(continued)

Listing 10-4 (continued)

private static DecimalFormat decFormat = new DecimalFormat( 000 ); public PlayerPlus(String name, double average) { super(name, average); playerCount++; totalOfAverages += average; } public static double findTeamAverage() { return totalOfAverages / playerCount; } public static String findTeamAverageString() { return decFormatformat (totalOfAverages / playerCount); } }

Maybe you ve noticed the code in Listing 10-4 is overflowing with the word static That s because nearly everything in this code belongs to the entire PlayerPlus class and not to individual instances of the class That s good because something like playerCount (the number of players on the team) shouldn t belong to individual players, and having each PlayerPlus object keep track of its own count would be silly ( I know how many players I am I m just one player! ) If you had nine individual playerCount variables, either each variable would store the number 1 (which is useless) or you would have nine different copies of the count, which is wasteful and prone to error So by making playerCount static, you re keeping the playerCount in just one place, where it belongs The same kind of reasoning holds for the totalOfAverages Eventually, the totalOfAverages variable will store the sum of the players batting averages For all nine members of the Hankees, this adds up to 956 It s not until someone calls the findTeamAverage or findTeamAverageString method that the computer actually finds the overall Hankee team batting average

You also want the methods findTeamAverage and findTeamAverageString to be static Without the word static, there would be nine findTeamAverage methods one for each instance of the PlayerPlus class This wouldn t make much sense Each instance would have the code to calculate totalOf Averages/playerCount on its own, and each of the nine calculations would yield the very same answer In general, any task that all the instances have in common (and that yields the same result for each instance) should be coded as a static method Constructors are never static In Listing 10-4, the decFormat variable is static This makes sense, because decFormat makes totalOfAverages / playerCount look nice, and both variables in the expression totalOfAverages / playerCount are static Thinking more directly, the code needs only one thing for formatting numbers If you have several numbers to format, the same decFormat thing that belongs to the entire class can format each number Creating a decFormat for each player is not only inelegant, but also wasteful In this book, my first serious use of the word static is way back in Listing 3-1 I use the static keyword as part of every main method (and lots of main methods are in this book s listings) So why does main have to be static Well, remember that non-static things belong to objects, not classes If the main method isn t static, you can t have a main method until you create an object But, when you start up a Java program, no objects have been created yet The statements that are executed in the main method start creating objects So, if the main method isn t static, you have a big chicken-and-egg problem