Discussion 2 handout
Group members (names & NetIDs)
Objectives
- Notes on Arrays in Java
- Exploring Inheritance and Polymorphism
- Bonus teaser on Java’s ADT
Prepration: Download and set up the project
Please start with downloading source code we will be using in the discussion: code. For this activity and extract the Zip file to a known location on your computer. set it up as a project in IntelliJ just as you would an assignment.
Task 1: Notes on Arrays
Finish the TODOs 1 - 6 in Arrays.java
following the instructions given in the comments. And record the code snippet in a text file.
Task 2: Bounding boxes and black-box testing (Skip this task, if you’re confident in testing)
In a graphical design program (like PowerPoint), a bounding box is an axis-aligned rectangle in a 2D plane that encloses (“bounds”) one or more 2D shapes. They may be used to operate on those shapes as a group and to optimize queries over large numbers of shapes.
Consider the following method specification in the BoundingBox
interface:
/**
* Determine whether the specified point is contained strictly within the
* interior of this box. Points on the boundary of the box are not considered to
* be contained within its interior.
*
* @param p The point to perform the interior test on. Non-null.
* @return True if <code>p</code> is strictly within the interior of this box;
* otherwise false.
*/
boolean contains(Point p);
Open BoundingBoxTest
under “tests” and add the JUnit 5 dependency. Your goal is to write a test suite thorough enough to catch all of the bugs in the contains()
implementation in classes BB1
–BB3
, which implement the BoundingBox
interface (some implementations are correct, but others are not).
Write a different test procedure for each “situation” you are testing (e.g. inside the box, outside the box, on an edge, on a corner, etc.), and be sure to add the @Test
annotation above each procedure. Within each procedure, you may have multiple JUnit assertions involving different points or different boxes.
Each test should involve the creation of a BoundingBox
and a Point
and should use assertTrue()
or assertFalse()
to indicate the expected outcome for whether that point is contained within the box. Use the makeBoundingBox()
method instead of invoking constructors directly so that you can easily swap out which class you are testing (if your test procedures only use the BoundingBox
interface, and not class names, as the static type, they will not need to change).
Write as many test cases as you think are necessary to be confident that the method is implemented correctly, but try to avoid redundancy in your cases—each case should exercise the method in a different geometric regime. Summarize your group’s test cases on your worksheet (indicate the rectangle, the point, and the expected result).
Bugs
The “dis02” project provides several classes implementing the BoundingBox
interface, named BB1
through BB3
. They showcase how to implement the interface using different sets of fields to represent its state, but some have buggy implementations of contains()
. Run your test suite for each implementation; which classes do you think are implemented correctly?
Task 3: Interface Polymorphism
Can you define a new class named BB4 that implements the BoundingBox Interface differently than the implementations in BB1, BB2 and BB3? For some ideas, you can think of the different ways in which we can represent a box in 2D space. What kind of Polymorphism is this?
Task 4: Subtype Polymorphism
Note
: Don’t worry if this task gets too overwhelming for you. You’re not meant to understand
everything right away. We’ll be exploring a lot of topics introduced here in more detail in later
lectures. Just use it as an exploratory exercise on inheritance.
What is a feature that was lacking in Java arrays? Hint: Refer back to your notes from Task 1.
Try to replace the uses of Java arrays in Arrays.java and reimplement the code snippet in Task 1 using the NeverFailArray class given in the starter code by following the TODOs in NewArrays.java. Re-run your code and report if the problem you talked about earlier now exists in the new implementation of the code?
Can the NeverFailArray be extended to support arbitrary types? How would you do this? What kind of Polymorphism would this be if that were possible?
Hint: Try to look at how Java’s List library supports this for the list interface.
Note
: Don’t worry about the clunky looking syntax with the <Type>
for now. Just treat it as a placeholder that will be replaced with a proper Java type or Class at some point during initialization.
Bonus
: Go back to TODO 3 in Task 3. What types would you have to be able to support in order
to implement a 2D int[][] array?
Task 5: Revisiting Interface Polymorphism
Have you noticed that all the versions of Arrays.java have a lot of de-duplicated code?
All the main method in Arrays.java in java does is to generate a list of 1000 random Strings
and computes the occurrence of each character (a … z) and tabulates them in the counts array.
I will admit that its not a particularly interesting or meaningful piece of logic to replicate.
But for pedagogical purposes, can you think of a way of restructuring the logic in this file
to reduce the amount of reduplicated code across the files in the arrays folder.
Hint: Think of designing an interface that prevents us from having to implement the main
method over and over again.
Write down your thoughts after attempting this exercise.
Submission
Open the assignment page for “Discussion activity 2” in CMSX and turn in your solution in one document. Note that this is graded for participation and not credit.