# Homework 2: Counter Varieties

• Out on: September 11, 2017
• Due by: never
• Collaboration: open-ended

Homework is important practice for you, but it’s not graded so you don’t have to submit it. This particular homework is designed to help you practice programming with interfaces and basic unit testing (via Java’s `assert` mechanism for now).

## Overview

You will develop several implementations of the `Counter` interface we discussed in lecture. Each of your implementations will contain a `main` method for basic unit testing. All of your implementations will also “plug into” a general, polymorphic test program called `PolyCount`. Start by grabbing the `Counter.java` and `PolyCount.java` files from the Piazza post for this homework assignment.

## The Counters

You need to develop a total of three implementations of the `Counter` interface as follows:

• An implementation called `BasicCounter` that starts at the value 0 and counts up and down by +1 and -1 respectively. (This is exactly what we did in lecture already, but it helps to do it “from scratch” one more time to get used to the recommended “baby steps” approach to programming.)
• An implementation called `SquareCounter` that starts at the value 2, counts up by squaring its current value, and counts down by taking the square root of its current value. (You should always round up when taking the square root, i.e. 1.7 is rounded to 2, just like 1.2 is rounded to 2).
• An implementation called `FlexibleCounter` that allows clients to specify a (non-negative!) starting value as well as a (positive!) delta value in the constructor. (The delta value is added to the current value when counting up, but subtracted from the current value when counting down.)

After you’ve done it once for `BasicCounter` the other two are just variations on the theme, but you’ll have to look up some additional Java things for each which makes for good review.

### Unit Testing

All of the implementations above should contain a `main` method that tests whether the implementation works as expected. You should use Java’s `assert` mechanism for testing just like we did in lecture: The tests should “do nothing” if they pass, but “explode” very visibly if one of them fails.

Note that the unit tests in `main` should test exactly that counter, not what a weaker, more general specification would make you test. So presumably each will test against a fixed sequence of expected results from `value()` after certain `up()` and `down()` calls have been executed. Make sure that you test the obvious boundary conditions carefully (if there are any), most importantly for a `SquareCounter` counting down.

### The PolyCount Program

Before you continue, be sure to actually read the `PolyCount.java` file, it contains some relevant information in comments. Once you have the three counters implemented, you should be able to compile and run `PolyCount` without any errors/exceptions. If you cannot, something is wrong with your code; try to figure out what it is and fix it.

### Hints

• Pay close attention to your use of `public` and `private`! The essence of our counters is not just to hold a bunch of data, but to ensure that a certain approach to counting is being followed; making everything `public` is a bad idea.
• For unit testing with `assert` please remember that you need to run the test with the `-enableassertions` (aka `-ea`) flag.
• You can also use `assert` in the constructor for `FlexibleCounter` to make sure that the arguments you’re getting fulfil the constraints that have been placed on them…

## Adding More Interfaces

You should only try this once you have finished the work above and all the test cases (your own as well as `PolyCount`) pass. You will now “rework” your counters to add another feature, and you’ll do it with interfaces:

• Define an interface `Resetable` with a single `void reset()` method in it; this interface models the generic property of being able to “reset something to its initial state” regardless of whatever that something is. (In that sense it’s similar to `Lockable` as discussed in lecture.)
• Define an interface `ResetableCounter` that extends both the `Counter` interface and the `Resetable` interface; we gather that it’s obvious what the meaning of that interface is.
• Change your `BasicCounter`, `SquareCounter`, and `FlexibleCounter` classes to implement the `ResetableCounter` interface instead of the `Counter` interface. (You’ll have to write a `reset()` method for each class, and you should add testing for `reset()` to your unit tests for each class.)

This is not a lot of work, but if you’re new to interfaces you might have a hard time getting started. Don’t be shy and come to office hours if you cannot figure it out on your own!

### The PolyCount Program

There should be nothing to do for `PolyCount` even after you’ve performed major surgery on your counters to make them resetable. If the `PolyCount` program no longer compiles or throws an exception after your modifications, you did something wrong somewhere along the way; try to figure out what it is and fix it.

### Hints

• Interfaces can extend one another in a way similar to classes (using the `extends` keyword), but classes implement interfaces (using the `implements` keyword). An interface can extend multiple interfaces, a class can implement multiple interfaces, but a class can only extend one other class.

## Artifacts

At minimum, you should have the files `BasicCounter.java`, `SquareCounter.java`, `FlexibleCounter.java`, `Resetable.java`, and `ResetableCounter.java`; of course you also need our `Counter.java` and `PolyCount.java` files for completeness. All of these should compile without warnings with the `-Xlint:all` flag; there should be no `checkstyle` warnings either with the 601.226 configuration file posted on Piazza.