Adding equals method. This method comes together with hashCodemethod. For those who haven’t done this yet, I would recommend to spend 5 minutes and read about them in Javadoc. Here is the next version of the Rectangle class.

public class Rectangle {

    // ... same properties with getters and setters as before

    @Override
    public int hashCode() {
        return (int) width + 13 * (int) height;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }
        if (!(obj instanceof Rectangle)) {
            return false;
        }
        Rectangle other = (Rectangle) obj;
        return other.width == width && other.height == height;
    }

}

The outcome of previous code after adding equals and hashCode methods.

Rectangle rect1 = new Rectangle();
rect1.setWidth(1);
rect1.setHeight(2);
Rectangle rect2 = new Rectangle();
rect2.setWidth(1);
rect2.setHeight(2);

System.out.println(rect1.equals(rect1));      // true
System.out.println(rect2.equals(rect2));      // true
System.out.println(rect1.equals(rect2));      // true
System.out.println(rect2.equals(rect1));      // true

List list = new ArrayList<>();
list.add(rect1);
System.out.println(list.contains(rect1));     // true
System.out.println(list.contains(rect2));     // true

Set set = new HashSet<>();
set.add(rect1);
System.out.println(set.contains(rect1));     // true
System.out.println(set.contains(rect2));     // true

Map<Rectangle, Integer> map = new HashMap<>();
map.put(rect1, 2);
System.out.println(map.containsKey(rect1));     // true
System.out.println(map.containsKey(rect2));     // true

You see, rectangles are considered to be equal and it is possible to test whether collections contains the specific one. Then the test case for RectangleParser can be rewritten in this way.

RectangleParser parser = new YourSuperParser();
List expected = Arrays.asList(... insert the rectangles...);
List rects = parser.parse("rectangle[1,2],recangle[2,3]");
assertEquals(expected, rects);

This is much better, because objects are deeply compared. Such tests are much more robust than the previous ones so developers can seamlessly catch and fix the (side) effects of the code changes. Seems like a problem solved. Unfortunately such way brings another issue. Look at this.

Rectangle rect1 = new Rectangle();
rect1.setWidth(1);
rect1.setHeight(2);
Rectangle rect2 = new Rectangle();
rect2.setWidth(1);
rect2.setHeight(2);

Set set = new HashSet<>();
set.add(rect1);
System.out.println(set.contains(rect1));     // true
System.out.println(set.contains(rect2));     // true

rect1.setWidth(5);

System.out.println(set.contains(rect1));     // false
System.out.println(set.contains(rect2));     // false

Now rectangle was inserted to the set. Since both rectangles are equal, then set returns true when calling contains method. Next, original rectangle was changed. That means it’s hash code value changed as well. But set isn’t aware of this change. That means it keeps the object in the wrong bucket. And therefore it looks like the rectangle disappeared from the set. In this example it is easy to spot, but it’s very hard to find it when same situation happens in a large system. This means that invocation of public method can easily break completely different portion(s) of the application.

This is the problem of all mutable patterns. You might solve it by convention to say, no one is going to call setter after the object is constructed. It might or might not work out for you. I have personally chosen not to rely on such convention.