Methods Common to All Objects

This is a fundamental problem with equivalence relations in object-oriented languages:

1. Adding a value component creates a dilemma:

   • If subclass ignores the new component in equals → violates "equals means logically equivalent"
   • If subclass considers the new component → breaks symmetry with parent class

2. Attempted solutions all fail:

   • Mixed-type comparison breaks transitivity (e.g., ColorPoint p1 equals Point p2, Point p2 equals ColorPoint p3 with different color, but p1 does not equal p3)
   • Using getClass() instead of instanceof breaks Liskov Substitution Principle
   • Two-way interoperability creates risk of infinite recursion between different subclasses

3. Recommended workaround: Use composition instead of inheritance - give the "extended" class a private field of the base class type and a view method to expose it when needed.

You should NOT override the equals method when any of these conditions apply:

1. Each instance is inherently unique - Such as with active entities (e.g., Thread) rather than value objects. The default Object.equals implementation is appropriate.

2. No need for "logical equality" test - When clients don't need to compare instances for logical equivalence (e.g., java.util.regex.Pattern doesn't need to compare if two patterns represent the same regex).

3. Superclass has already overridden equals appropriately - If a parent class already implements equals in a way that works for your class (e.g., most Set implementations inherit equals from AbstractSet).

4. Class is private or package-private and equals will never be invoked - When you're certain the method won't be called, though you might defensively override it to throw AssertionError.

5. Class uses instance control (Item 1) - If at most one object exists with each value (like Enum types), logical equality is the same as object identity.

When equals() is overridden without hashCode(), equal objects can have different hash codes, violating the hashCode contract that states "equal objects must have equal hash codes."

Consequences in collections:

1. HashMap/HashSet operations degrade from O(1) to O(n) performance
2. Objects can't be found even when they "exist" in the collection
3. Duplicate objects can be stored in sets that should prevent duplicates

Example:

// Without proper hashCode()
Map<PhoneNumber, String> m = new HashMap<>();
m.put(new PhoneNumber(707, 867, 5309), "Jenny");
m.get(new PhoneNumber(707, 867, 5309)); // Returns null!

The get() method looks in a different hash bucket than where put() stored the entry.

Recipe for a high-quality hashCode() implementation:

1. Declare an int variable result, initialize it to the hash code of the first significant field.

2. For each remaining significant field f: a. Compute hash code c for the field:

   • Primitive field: Type.hashCode(f) (e.g., Integer.hashCode(f))
   • Object reference: Recursively call f.hashCode() (use 0 if null)
   • Array: Treat each significant element as separate field or use Arrays.hashCode()

   b. Combine into result: result = 31 * result + c;

3. Return result

Example for PhoneNumber:

@Override public int hashCode() {
    int result = Short.hashCode(areaCode);
    result = 31 * result + Short.hashCode(prefix);
    result = 31 * result + Short.hashCode(lineNum);
    return result;
}

Note: Only include fields used in equals() comparisons. Derived fields can be excluded if they're calculated from included fields.

Extending a Comparable class with a new value component breaks the contract because:

1. Violation of symmetry rule: If a subclass instance S is compared to a superclass instance P:

   • S.compareTo(P) might consider the new field, giving result X
   • P.compareTo(S) can't consider the new field, potentially giving result -X
   • This violates the rule that sgn(x.compareTo(y)) must equal -sgn(y.compareTo(x))

2. Violation of transitivity: Consider objects A, B, C where:

   • A is a subclass instance with new value component = 10
   • B is a superclass instance with all shared fields equal to A
   • C is a subclass instance with same shared fields but new value component = 20
   • A.compareTo(B) might return 0 (if ignoring subclass field)
   • B.compareTo(C) might return 0 (if ignoring subclass field)
   • A.compareTo(C) should return -1 (due to 10 < 20)
   • This breaks transitivity: if A = B and B = C, then A must = C

Solution: Instead of extending the class, create a new class containing an instance of the original class and provide a "view" method to retrieve it when needed.

Immutable classes should avoid providing clone() methods because:

1. Wasteful copying: Since immutable objects can't change, creating a copy serves no logical purpose
2. Violation of immutability pattern: Clone creates a second object that is identical but not the same object
3. Performance impact: Unnecessary object creation increases memory usage and garbage collection overhead
4. Instance control subversion: Classes that use instance control (like singletons or enum types) may have their control circumvented by cloning
5. Contradicts the purpose of immutability: Immutable objects are inherently thread-safe and shareable without defensive copying
6. Breaks canonicalization: If a class caches objects (like Integer.valueOf()), cloning defeats this optimization

For immutable objects, alternatives to cloning include:

• Simply using the original object (reference)
• Factory methods that return the same instances for equal values
• Static factory methods for creating derived objects (like String.substring())

Example of what NOT to do:

// Unnecessary and incorrect for immutable classes:
@Override public PhoneNumber clone() {
    try {
        return (PhoneNumber) super.clone();
    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

// Iteratively copy the linked list headed by this Entry
Entry deepCopy() {
    // Create first node
    Entry result = new Entry(key, value, null);
    
    // Use iteration instead of recursion to avoid stack overflow
    Entry current = result;
    Entry original = this.next;
    
    // Iterate through the original list, creating new nodes
    while (original != null) {
        current.next = new Entry(original.key, original.value, null);
        current = current.next;
        original = original.next;
    }
    
    return result;
}

Key advantages:

• Uses constant stack space regardless of list length
• Prevents stack overflow errors when cloning long lists
• Creates completely independent copies of all nodes
• Maintains the same ordering of elements as the original list
• Uses a single linear traversal (O(n) time complexity)

Better alternatives to Cloneable:

1. Copy Constructor:

   public Yum(Yum original) {
       this.field1 = original.field1;
       this.field2 = new ArrayList<>(original.field2); // Deep copy if needed
       // Copy remaining fields
   }

2. Static Copy Factory:

   public static Yum newInstance(Yum original) {
       Yum copy = new Yum();
       copy.field1 = original.field1;
       copy.field2 = new ArrayList<>(original.field2);
       return copy;
   }

Advantages over Cloneable/clone:

• No dependence on error-prone extralinguistic object creation mechanism
• No need to catch checked exceptions
• No reliance on conventions that can't be enforced
• No conflicts with final fields
• No requirement for casting
• Can accept interfaces as parameters (conversion constructors/factories)
• Allow choosing implementation type of copy (e.g., copy HashSet to TreeSet)
• More clearly express intent in code

Exception: Arrays are best copied with clone() method.

For thread-safety in a clone() method:

// Thread-safe clone implementation
@Override
public synchronized MyThreadSafeClass clone() {
    try {
        MyThreadSafeClass result = (MyThreadSafeClass) super.clone();
        // Perform any necessary deep copying here
        return result;
    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

Critical requirements:

• Add the synchronized keyword to the clone method
• Even if super.clone() implementation is satisfactory in other respects, it's not synchronized
• Without synchronization, the object's state may be corrupted if modified by another thread during cloning
• All methods that can modify object state must be synchronized in a thread-safe class
• The clone() method is no exception to this rule

This ensures thread safety without risking race conditions during the cloning process.

The critical lexicographic ordering pattern:

1. Start comparison with the most significant field
2. If comparison yields anything other than zero (not equal), immediately return that result
3. If comparison equals zero, proceed to next most significant field
4. Continue comparing fields in decreasing order of significance
5. If all fields are equal, return zero

Example code:

public int compareTo(ComplexObject obj) {
    // Compare primary field (most significant)
    int result = primaryField.compareTo(obj.primaryField);
    if (result != 0) return result;
    
    // Compare secondary field
    result = Integer.compare(secondaryField, obj.secondaryField);
    if (result != 0) return result;
    
    // Compare tertiary field
    result = tertiaryField.compareTo(obj.tertiaryField);
    return result; // Will be 0 if all fields equal
}

This pattern ensures: • Minimal field comparisons (early exit optimization) • Proper lexicographic ordering • Transitive comparison results • Stable sorting behavior