OBJECTIVE
This lab will give you additional practice in creating classes and objects. You are also building up a collection of simple classes that might be useful in future assignments and projects.
One of the libraries that instructors in the some of the CSC 151 courses have been supplying to their students implements an abstract data type called counter.
You can think of a counter as a simulation of those old-fashioned hand-held clickers that people used to use to count attendees at a county fair as they pass through the turnstile at the entrance gate or to tally cars as they cross a bridge.
Such a clicker is basically a numerical display with a tally button that increments the number displayed and a reset button to reset that number to zero.
The implementation of this data type in CSC 151 provides a constructor (counter-new), an accessor (counter-get), and restricted mutation procedures for incrementing the internal tally and resetting it to zero (counter-increment and counter-reset).
Reimplement this ADT as a Java class, Counter, and test the followings after instantiating Counter in the main method of your tester program (a.k.a. client program):
Remember:
In the implementation of counters in CSC 151, each counter produced by the constructor actually carries around a name which is specified as a string argument to the constructor.
This name is supposed to be immutable, since none of the ADT procedures modify it, and it is used only by a counter-print procedure that displays the internal state of the counter.
name field to your Counter class.String argument to the constructor that you wrote earlier that takes a name of the counter.toString method that constructs and returns a String consisting of the counter’s name, a colon, a space, and the current tally.(2 points) Test these features by creating at least two instances of a counter, incrementing their values several times (but a different number!), and calling the toString method to display the string representation of the counters.
A slightly more sophisticated device is the averager, which allows the user to add any number, not just 1, to a running total that it maintains, and also keeps track of the number of addends that it has received since it was created or last reset.
The averager can divide its running total by its running tally of addends to report the arithmetic mean of all of those addends.
For a minimal implementation, you’ll need a constructor, a mutator that takes a numerical argument and adds it to the running total (simultaneously incrementing the addend tally behind the scenes), a mutator that resets both the running total and the addend tally to 0, and an accessor that gives you the average of the addends.
The arithmetic mean is undefined when the addend tally is 0. In this special case, the accessor method should return 0 after printing a brief error report to System.err ( e.g. System.err.println("Error message here"); ), which is a PrintStream analogous to C’s stderr file descriptor.
(2 points) Implement and test an Averager class:
Prepare your lab write-up until this point. Then, continue working on the following features.
Other potentially useful features for averagers include separate accessors for the running total and the addend tally, toString and equals methods, accessors for the maximum and minimum values among the addends seen so far, and a method that takes another Averager as argument and combines its running total and addend tally with the running total and addend tally of this averager.
Note that the equals method takes Object as its parameter. Thus, you need to do a type conversion.
Prepare your lab write-up to submit by the end of the week. You should submit the content of Counter.java and Averager.java along with the tester application. Add comments to help the grader find the appropriate sections of code to answer each question.
I strongly recommend that each student keep a copy of the lab. Therefore, don’t forget to share the files/folder with your lab partner!