عرض عملي: إعادة هيكلة وراثة سيئة إلى تركيب

Written Explanation

Step 1: the provided hierarchy

The library class you will start from is a small list of ints, written for this lesson. It supports adding at the end, adding at an index, removing by index, reading, and asking its size:

public class IntList {
    private int[] items = new int[10];
    private int size = 0;

    public void add(int value) {
        items[size] = value;
        size++;
    }

    public void add(int index, int value) {
        for (int i = size; i > index; i--) {
            items[i] = items[i - 1];
        }
        items[index] = value;
        size++;
    }

    public int remove(int index) {
        int removed = items[index];
        for (int i = index; i < size - 1; i++) {
            items[i] = items[i + 1];
        }
        size--;
        return removed;
    }

    public int get(int index) { return items[index]; }
    public int size() { return size; }
    public boolean isEmpty() { return size == 0; }
}

(The array has room for ten values only, to keep the code short. A real list grows; the standard library's lists do. It does not matter for this lesson.)

A teammate wanted a stack and, because a stack stores items in order, reused it with extends:

public class BadStack extends IntList {
    public void push(int value) { add(value); }
    public int pop() { return remove(size() - 1); }
    public int peek() { return get(size() - 1); }
}

It looks tidy: three one-line methods, no repeated code. The is-a sentence, though, sounds forced: "a stack is an int list". A stack is something you use only from one end.

Step 2: show the break and name the rule

A stack has one rule: last in, first out. The only way in is push, the only way out is pop. But BadStack inherited every public method of IntList. Try this:

BadStack s = new BadStack();
s.push(1);
s.push(2);
s.push(3);
s.add(0, 99);      // inherited: inserts at the bottom
s.remove(1);       // inherited: removes from the middle
System.out.println(s.pop());
System.out.println(s.pop());
System.out.println(s.pop());

It compiles and prints:

3
2
99

A real last-in-first-out stack holding 1, 2, 3 would give 3, 2, 1. Here the 1 is gone and a 99 appeared at the bottom, because callers used the inherited add(index, value) and remove(index).

Name the broken rule in one sentence: "BadStack inherits add(index, value) and remove(index), which let any caller break last-in-first-out." This sentence is also the first half of the explanation the lab asks for.

The same problem exists with a standard library class: the Java documentation for java.util.Stack shows that it extends Vector, and it recommends using Deque implementations instead for stack operations. It is a historical example of the trap. Lists and Deque come in a later module; here you only need to see that even the library has the problem.

Step 3: hold the list in a private field

Create a class with the same job but has-a instead of is-a:

public class Stack {
    private final IntList items = new IntList();
    ...
}

The field is private so nobody outside can touch it, and final so the stack always uses the same list. This is the whole structural change: extends IntList becomes private final IntList items.

Step 4: forward only what should stay

Expose exactly the operations a stack promises: push, pop, peek, isEmpty. Each one forwards to the list:

public class Stack {
    private final IntList items = new IntList();

    public void push(int value) { items.add(value); }

    public int pop() {
        if (items.isEmpty()) {
            System.out.println("Stack is empty");
            return -1;
        }
        return items.remove(items.size() - 1);
    }

    public int peek() {
        if (items.isEmpty()) {
            System.out.println("Stack is empty");
            return -1;
        }
        return items.get(items.size() - 1);
    }

    public boolean isEmpty() { return items.isEmpty(); }
}

(Returning -1 for an empty stack is a placeholder for the lab; a later module shows a better way to report errors.)

Use it:

Stack s = new Stack();
s.push(1);
s.push(2);
s.push(3);
System.out.println(s.pop());
System.out.println(s.peek());

3
2

Now try the old abuse, s.add(0, 99);. It no longer compiles:

Main.java:9: error: cannot find symbol
        s.add(0, 99);
         ^
  symbol:   method add(int,int)
  location: variable s of type Stack

The compiler now enforces the rule. The unwanted methods did not become "discouraged"; they are simply absent.

Step 5: the planned mistake, a leaking getter

A common slip while refactoring: someone adds a convenient getItems() that returns the internal list:

public IntList getItems() { return items; }

The class compiles, and the old attack works again, now through the back door:

s.getItems().add(0, 99);
s.getItems().remove(1);

Popping three times prints 3, 2, 99, the same broken order as before. The leak gives callers the inner object, with all its methods, so encapsulation is lost. Two fixes: remove the getter, which is best when nobody needs it, or return a copy or a read-only view of the data. If callers only need the count, add a size() that forwards to items.size() and nothing else.

This is the same lesson as returning internal mutable arrays from the previous module: returning an internal mutable object hands over control.

Step 6: explain the refactor in two sentences

The lab requires a short explanation. A good one is:

Stack extends IntList was wrong because a stack is not a kind of list: it inherited methods that insert or remove in the middle and break last-in-first-out. Now Stack holds an IntList in a private field and forwards only push, pop, peek, and isEmpty, so the rule can no longer be broken from outside, and the list can be replaced later without changing callers.

Notice the structure: (1) what was wrong and which rule broke, (2) what the new design does and what it gains.