Classes and Interfaces

Rule: Make each class or member as inaccessible as possible.

This means using the lowest possible access level consistent with proper functionality.

Why fundamental:

• Enforces information hiding/encapsulation
• Decouples components in a system
• Allows components to be developed, tested, and modified in isolation
• Enables effective performance tuning
• Increases software reuse potential
• Decreases dependency risks in large systems

Implementation: Use private, package-private, protected, and public modifiers in order of increasing accessibility.

The correct approach is to implement Entry as a private static member class because:

1. Entry methods (getKey(), getValue(), setValue()) don't need access to the enclosing Map instance
2. Using a static member class avoids storing unnecessary references to the enclosing Map
3. The static approach prevents potential memory leaks by allowing the Map to be garbage collected when no longer needed
4. It improves performance by reducing memory overhead

public class HashMap<K,V> {
    // Other implementation details...
    
    // Correct implementation
    private static class Entry<K,V> {
        final K key;
        V value;
        // Methods don't need Map instance access
        public K getKey() { return key; }
        public V getValue() { return value; }
        public V setValue(V newValue) {
            V oldValue = value;
            value = newValue;
            return oldValue;
        }
    }
}

Two implicit module-based access levels:

1. Module-private public members: Public and protected members of public classes in unexported packages
2. Module-private protected members: Protected members of public classes in unexported packages

Limitations of utility:

1. Advisory nature: If you place a module's JAR on the classpath (not module path), these restrictions disappear
2. Implementation complexity: Requires grouping packages into modules, explicit module declarations, source tree reorganization
3. Compatibility challenges: Requires special handling for access to non-modularized packages
4. Limited adoption: Not widely used outside the JDK itself
5. Learning curve: Adds complexity compared to traditional access control mechanisms

Practical implication: Most Java programmers should focus on the four traditional access levels (private, package-private, protected, public) unless there's a compelling need for module encapsulation.

Current recommendation: Avoid relying on module-based access levels unless specifically needed for large systems with clear module boundaries.

Issues with public mutable fields:

1. No control over values: Cannot limit what values are stored in the field
2. No invariant enforcement: Cannot ensure field values maintain class invariants
3. No state transition control: Cannot execute additional code when the field changes
4. API lock-in: Cannot change the internal representation in future releases
5. Thread-safety violation: Cannot synchronize access to the field

Thread-safety problems:

• Multiple threads can modify the field simultaneously without coordination
• Modifications by one thread may not be visible to other threads (memory visibility issues)
• Race conditions can occur when operations aren't atomic
• Cannot perform thread-safe compound operations on the field
• Impossible to ensure consistent object state across related fields

Example of vulnerability:

public class UnsafeCounter {
    public int count;  // Thread-unsafe
    
    // Multiple threads calling increment() will lose updates
    public void increment() {
        count++;  // Not atomic, can result in lost updates
    }
}

Better approach: Use private fields with synchronized accessor methods or thread-safe data structures.

The problem is self-use in the parent class, which violates encapsulation and creates fragile code:

1. When overriding methods like add() and addAll() in a subclass of HashSet:
   • HashSet.addAll() internally calls add() for each element
   • The overridden add() in the subclass is called by the parent's implementation
2. This causes double-counting when tracking additions:

   // When executing this code:
   InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
   s.addAll(List.of("Snap", "Crackle", "Pop"));
   
   // Expected count: 3
   // Actual count: 6 (each element is counted twice)

This demonstrates why implementation inheritance breaks encapsulation - the subclass depends on implementation details of the superclass that aren't part of its contract.

Immutable objects are inherently thread-safe because:

1. Their state cannot change after construction
2. No thread can ever observe the effects of another thread on the object
3. No synchronization is required when multiple threads access them

Specific advantages in concurrent programming:

• Zero race conditions: No need for locks, synchronization blocks, or volatile fields
• Free sharing: Can be freely shared between threads without defensive copying
• Consistent views: All threads always see the same state
• Atomic state transitions: Moving from one state to another requires creating a new object, which is atomic
• No visibility issues: No need to worry about memory visibility problems that plague mutable objects

Example: String and BigInteger are thread-safe with no synchronization overhead, while their mutable counterparts (StringBuilder and BitSet) require careful synchronization in concurrent contexts.

Three common problems:

1. Dependency on self-use patterns:

   • Superclass internally calls its own methods (like addAll calling add)
   • Subclass overrides one method but not others in the self-use chain
   • Results in incorrect behavior (double-counting, invariant violations)
   • Example: InstrumentedHashSet counting elements added via addAll twice

2. Vulnerability to superclass evolution:

   • Superclass adds new methods in subsequent releases
   • These methods might bypass security or validation logic in subclasses
   • Example: Security vulnerabilities in collection classes that validate elements
   • Or: Superclass adds a method with the same signature but different return type as a subclass method

3. Exposure to implementation details:

   • Subclass depends on internal workings of superclass
   • Changes to superclass implementation break subclass behavior
   • Optimization limitations when superclass implementation can't be changed
   • Example: Having to maintain inefficient algorithms for backward compatibility

These problems stem from inheritance violating encapsulation by exposing implementation details that would normally be hidden.

When designing a class for inheritance, you permanently commit to:

1. Self-use patterns of overridable methods:

   • Which methods call which other methods internally
   • The sequence and timing of these calls
   • How return values affect subsequent processing

2. Implementation decisions exposed through protected methods:

   • Any protected method becomes part of the class's API
   • The behavior, parameters, and return values must be maintained
   • Subclasses will depend on current implementations

3. Implementation decisions exposed through protected fields:

   • Field types and semantics must be preserved
   • Field visibility cannot be reduced
   • Field behavior modifications may break subclasses

These commitments severely constrain future evolution because:

• You cannot change the internal calling patterns between methods
• You cannot remove or significantly modify protected members
• Performance optimizations might be impossible if they require restructuring internal method calls
• You must maintain backward compatibility with all possible subclass implementations
• You cannot know how subclasses might be using your protected members

This is why classes must be tested for inheritance before release, and why inheritance is appropriate only for genuine subtype relationships.

Advantages of interfaces over abstract classes:

1. Multiple implementations:

   • A class can implement multiple interfaces
   • Java only allows single inheritance for classes

2. Retrofitting existing classes:

   • Easy to add an interface to existing classes
   • Just implement required methods and add "implements" clause
   • Can't retrofit an abstract class without restructuring the hierarchy

3. Defining mixins:

   • Interfaces ideal for defining optional capabilities
   • Example: Comparable, Iterable, Autocloseable
   • Abstract classes can't define mixins due to single inheritance

4. Non-hierarchical type frameworks:

   • Interfaces allow combinations of capabilities
   • With n attributes, interfaces can represent all 2ⁿ combinations
   • Class hierarchies would require a separate class for each combination

5. Enable safer functionality enhancements:

   • Wrapper class idiom works better with interfaces
   • Abstract class hierarchies force inheritance for enhancements

Example showing combination capabilities:

// Base capability interfaces
public interface Swimmer { void swim(); }
public interface Flyer { void fly(); }
public interface Runner { void run(); }

// Combined capabilities - doesn't force a rigid hierarchy
public interface FlyingFish extends Swimmer, Flyer { }
public interface Duck extends Swimmer, Flyer, Runner { }

// Any class can implement these as needed
public class Penguin implements Swimmer, Runner { /*...*/ }
public class Eagle implements Flyer { /*...*/ }
public class Platypus implements Swimmer, Runner { /*...*/ }

With abstract classes, this flexibility would be impossible without massive code duplication.

An Adapter pattern using nonstatic member classes:

1. Allows an instance of the outer class to be viewed as an instance of an unrelated class
2. Creates a wrapper that implements a different interface than the outer class
3. Requires access to the enclosing instance's state/methods

Common examples:

• Map implementations use nonstatic member classes to implement Collection views (keySet, entrySet, values)
• Collection implementations use nonstatic classes for iterators

public class MyList<E> implements List<E> {
    // List implementation details...
    
    @Override
    public Iterator<E> iterator() {
        return new MyIterator(); // Returns adapter
    }
    
    // Adapter pattern using nonstatic member class
    private class MyIterator implements Iterator<E> {
        private int position = 0;
        
        @Override
        public boolean hasNext() {
            // Accesses enclosing instance's state
            return position < MyList.this.size();
        }
        
        @Override
        public E next() {
            // Accesses enclosing instance's methods
            return MyList.this.get(position++);
        }
    }
}