Skip to main content

ITSC 1213 - Introduction to CS 2 How to Design Programs with Object Oriented Programming

Nadia Najjar, Dhruv Dhamani

Section 12.13 Step 2: Defining the Class Structure and Signatures

Following our data definition in Step 1, we proceed to Design Recipe Step 2: Method Signatures & Purpose Statements. Typically, this is where you would carefully design the public "face" of your class – deciding on method names, parameter types, return types, and writing clear purpose statements (often as Javadoc) that define the contract for each method. This step translates the understanding from Step 0 and the data from Step 1 into a formal API blueprint.
🔗
However, in this capstone project, much of this work has already been done for us! Remember from Step 0 that our core task is to implement the provided ADTs.ListADT<T> interface. This interface already defines the required method signatures and their purposes (via its Javadoc comments).
🔗
Therefore, our Step 2 primarily involves formally declaring our class structure to reflect this requirement:
🔗
package DataStructures;

import ADTs.ListADT;
// Potentially other imports later (like NoSuchElementException, etc.)

/**
 * A dynamic array implementation of the ListADT interface.
 * Allows storing elements of type T, resizing as needed.
 * @param <T> the type of elements held in this list
 */
public class ArrayList<T> implements ListADT<T> {

    // --- Instance Variables (from Step 1) ---
    private T[] buffer;
    private int size;
    private static final int DEFAULT_CAPACITY = 10; // Example constant

    // --- Constructor (to be implemented in Step 5) ---
    // public ArrayList() { ... }

    // --- Methods (to be implemented in Step 5, matching ListADT) ---
    // Example:
    // @Override
    // public void add(int index, T item) {
    //     // Implementation goes here...
    // }

    // ... signatures for ALL other methods from ListADT and CollectionADT
    //     must be implemented here ...

}
The key elements here are:
🔗
  • The class declaration public class ArrayList<T> introduces our generic class with type parameter T.
    🔗
    🔗
  • The implements ListADT<T> clause formally states our promise to the compiler: this class will provide concrete implementations for all methods defined in the ListADT interface (and by extension, the CollectionADT interface it extends).
    🔗
    🔗
  • We include the instance variables derived in Step 1.
    🔗
    🔗
  • We anticipate needing a constructor and implementations for all the required methods.
    🔗
    🔗

Subsection 12.13.1 The Importance of @Override

When you provide the implementation for a method defined in an interface (like ListADT) or a superclass, it is strongly recommended best practice to use the @Override annotation just before the method signature:
🔗
@Override // Tells the compiler: I INTEND this to match a supertype method
public T get(int index) {
    // ... implementation ...
    return null; // Placeholder
}

@Override // Good practice for all implemented/overridden methods
public int size() {
    // ... implementation ...
    return 0; // Placeholder
}
What does @Override do? It asks the compiler to double-check that the method signature below it exactly matches a method signature from a superclass or an implemented interface. This is incredibly useful for catching common mistakes:
🔗
  • Typos: If you accidentally typed public int getsize() instead of size(), the compiler (seeing @Override) would immediately give you an error because no getsize() method exists in ListADT to override. Without @Override, it might silently compile as a *new*, unrelated method, leading to confusing behavior.
    🔗
    🔗
  • Parameter Mismatches: If the interface defined add(int index, T item) but you wrote add(T item, int index) (swapping parameters), @Override would flag this as an error because the signatures don’t match.
    🔗
    🔗
  • Return Type Mismatches: Similarly, if the interface expects a method to return boolean but your implementation returns void, @Override catches it.
    🔗
    🔗
Always using @Override provides a valuable safety net, turning potential runtime mysteries into clear compile-time errors. Get in the habit of using it for every method you implement from an interface or override from a superclass!
🔗
🔗
Since the specific method signatures and their detailed purposes are already defined by the ListADT interface and its Javadoc, we don’t need to redefine them here in Step 2. Our main task in this step was establishing the class structure that implements the interface.
🔗
Now that we have the overall class structure and know which methods (defined by ListADT) we need to implement, we move to Design Recipe Step 3: creating concrete examples and test cases to illustrate exactly how these methods should behave in various scenarios.
🔗
You have attempted of activities on this page.
🔗
PrevTopNext