Testing, Abstraction

• WhiteBox extends GreyBox — compliant. WhiteBox is a GreyBox with fill fixed to ' '. Since constructors are not inherited, a caller of GreyBox's interface methods has no expectation about how the fill colour was initially chosen. WhiteBox satisfies all of GreyBox's method contracts, with a stronger invariant on fill.
• BlackBox extends GreyBox — not compliant. BlackBox ties the fill colour to the frame colour, so calling setFrameColour has a side effect on getFillColour. A caller of GreyBox would not expect setFrameColour to change the fill — this violates the history constraint.
• ColouredBox extends GreyBox — not compliant. Although ColouredBox does not change the behaviour of any existing method, the additional setFillColour method allows the fill colour to be mutated after construction. GreyBox has an implicit history constraint — once constructed with a fill colour, that fill does not change. ColouredBox violates this.
• GreyBox extends WhiteBox — not compliant. WhiteBox has an invariant that fill is always ' '. GreyBox allows any fill colour, breaking this invariant.
• ColouredBox extends WhiteBox — not compliant. Violates both the fill invariant of WhiteBox and the history constraint, since setFillColour allows the fill to be changed after construction.
• BlackBox extends WhiteBox — not compliant. The fill colour is the frame character, which is not necessarily ' ', breaking WhiteBox's fill invariant.

A class declared final cannot be subclassed. A method declared final cannot be overridden. These are guarantees to the compiler and to readers of the code that no subclass will change the behaviour of the class or method in question.

This final keyword is useful when a class has been carefully designed with a specific contract and allowing subclasses to override behaviour could silently violate it.

Fields can be declared final, which means that they have to be set once when an object is constructed, and cannot be changed afterwards.

Local variables can also be declared final, which again means that they cannot be reassigned.

static final fields are also called constants, and the naming convention is for them to be in all caps:

An abstract class is a class that cannot be instantiated directly: it exists only to be extended. It may define fields and concrete methods that subclasses inherit, as well as abstract methods that subclasses must implement. Abstract classes occupy a middle ground between interfaces (no implementation) and concrete classes (full implementation).

In Java, abstract classes and methods are declared with the abstract keyword.

Our GuestList interface will represent a set of names. The interface exposes three operations:

The semantics are set-like: a guest is either coming or not; adding the same guest twice has the same effect as adding them once. The interface says nothing about how this is implemented — that is left to implementing classes.

A unit test checks a single, small piece of a program in isolation from the rest of the system. Unit tests contrast with integration tests, which test how multiple components work together.

JUnit is the standard unit-testing framework for Java. A JUnit test is an ordinary Java method annotated with @Test. Inside the method, special JUnit methods are used similarly to the assertions were used previously in this course:

• assertTrue(expr) — fails if expr is false
• assertFalse(expr) — fails if expr is true
• assertEquals(expected, actual) — fails if the two values differ
• Many more, see the JUnit documentation for a full list.

If any assertion fails, JUnit reports the test as failed and shows which assertion was violated.

Test-driven development (TDD) is a practice where tests are written before the implementation. The workflow is:

1. Write a test for the behaviour you want
2. Watch it fail (since there is no implementation yet)
3. Write the minimum implementation to make it pass
4. Repeat

This encourages thinking carefully about what a piece of code should do before thinking about how it should work. It also ensures that every piece of behaviour has a test from the start.

When writing tests we can take two perspectives on the code under test:

• In black-box testing, tests are written against the interface (or specification) only, without looking at the implementation. This is the preferred approach for unit-testing interfaces, because the tests remain valid across all implementations.
• In white-box testing, tests are written with knowledge of the implementation internals, targeting specific branches, edge cases, or internal states.

The following unit tests exercise the GuestList interface in a black-box fashion. To use JUnit in IntelliJ, create a new Java file and include the following imports at the top. You can run all tests in the file by pressing the green play button next to the class name, or run a single test by pressing the play button next to that test method.

Notice that the variable gl is declared as GuestList, not as a specific implementation class. This ensures the test targets the interface contract rather than any implementation detail, respecting abstraction boundaries. Each @Test method is independent: JUnit creates a fresh instance of the test class for each one, so the two tests do not interfere with each other.

The first implementation of the GuestList interface stores names in a plain String[] array. It is called lazy because add does not check for duplicates before inserting. Duplicates are only resolved later, at remove time, by nulling out all occurrences.

The lazy approach is simple but wastes space: the array may accumulate many nulls over time. When the array is filled up, we double its size (see Definition 3.7).

When an array-backed collection is full, we cannot simply extend it, because arrays have a fixed length. Instead, we create a new array of double the current size and copy all elements across. This makes any individual add that triggers a resize cost \(\mathrm {O}(n)\). However, such expensive calls are rare: after doubling, the next \(\frac {n}{2}\) insertions are cheap (\(\mathrm {O}(1)\) each).

Amortised analysis spreads the cost of an expensive operation across the many cheap operations that preceded it. If we charge each element a small constant at the time it is first inserted to "pre-pay" for its eventual copy, we find that each insertion costs \(\mathrm {O}(1)\) on average over any sequence of \(n\) insertions, even though individual insertions may cost \(\mathrm {O}(n)\).

To see that this is the case here, consider the overall cost of what we have done so far after \(n + 1\) insertions. In the worst case, we just had to double the size of the array for the last insertion, meaning that the array now has size \(2n\). That last doubling involved \(n\) copies. The doubling before that involved \(\frac {n}{2}\) copies. The one before that involved \(\frac {n}{4}\) copies. And so on. All of those copy operations sum up to less than \(2n\) copies. This means that per insertion (of the \(n + 1\) insertions we did so far), we made less than 2 copies (a constant), plus the constant amount of work for the insertion. The combination of those costs is still constant.

This implementation of GuestList is called strict (as opposed to the lazy implementation) because it enforces uniqueness eagerly: add calls isComing first and returns immediately if the guest is already present.

This implementation maintains the following data invariant: all non-null entries in data from 0 to count-1 are distinct. Because we are in the same package as GuestArrayList, we have access to its package-private fields and know about how its methods work. We also know that enforcing uniqueness changes nothing about the externally expected behaviour of the class. As such, we can make our new class a subtype of GuestArrayList, and use inheritance to reuse existing code, changing only what needs to be changed:

The add method is overridden to the isComing check first. However, after this check, the code of the method is the same as before, and we can just call the superclass' implementation of that method instead of copying it into here.

Because the invariant guarantees at most one copy exists, remove can stop after finding the first match. Contrast with the lazy implementation, where remove must scan the entire array to null out all copies. However, because this change to the code of remove is deep within the code of that method, we have to rewrite it fully, rather than calling the superclass' implementation.

Encapsulation means that the internal state of an object can only be changed through its defined methods. This is broken if a method returns a direct reference to an internal array or other mutable object, because the caller can then modify it from outside.

The fix is to return instead a defensive copy: a fresh object with the same contents. The caller is then free to do whatever they like with the copy without affecting the internal state of the object.

Suppose we extend the GuestList interface with a method coming() that returns the current list of guests. This seems straightforward, but a naive implementation illustrates a common encapsulation hazard: returning a direct reference to the internal array.

A caller who receives this reference can write list.coming()[0] = "Intruder" and corrupt the guest list without going through add or remove, potentially breaking the data invariant. The correct fix is to return a defensive copy: