1. The Three Pillars of OOP#

• Encapsulation: Combines private fields with public methods to hide internal implementation details and control access.
• Inheritance: Uses extends to promote code reuse and establish an is-a relationship.
• Polymorphism: Combines method overriding with upcasting to enable “one interface, multiple implementations,” decoupling callers from concrete logic.

Polymorphism is the most valuable aspect of Object-Oriented Programming. Programming to an interface rather than a concrete implementation forms the foundation of design patterns like Strategy and Spring’s Dependency Injection:

1
interface PaymentService {
2
    void pay(long amountInCents);
3
}
4

5
class AlipayService implements PaymentService {
6
    public void pay(long amountInCents) {
7
        System.out.println("Paid via Alipay: " + amountInCents);
8
    }
9
}
10

11
class WechatPayService implements PaymentService {
12
    public void pay(long amountInCents) {
13
        System.out.println("Paid via WeChat Pay: " + amountInCents);
14
    }
15
}
16

17
// Caller depends only on the interface; switching implementations requires zero code changes here
18
class CheckoutController {
19
    private final PaymentService paymentService;
20

21
    CheckoutController(PaymentService paymentService) {
22
        this.paymentService = paymentService;
23
    }
24

25
    void checkout() {
26
        paymentService.pay(9900);
27
    }
28
}

2. Initialization Order#

Parent and child classes follow a strict initialization order. This is a favorite technical interview topic and a key concept when debugging unexpected null field values.

Execution Order:

1. Parent static members/blocks (in order of appearance)
2. Child static members/blocks
3. Parent instance members/blocks
4. Parent constructor
5. Child instance members/blocks
6. Child constructor

1
class Parent {
2
    static { System.out.println("1 - Parent Static Block"); }
3
    { System.out.println("3 - Parent Instance Block"); }
4
    Parent() { System.out.println("4 - Parent Constructor"); }
5
}
6

7
class Child extends Parent {
8
    static { System.out.println("2 - Child Static Block"); }
9
    { System.out.println("5 - Child Instance Block"); }
10
    Child() { System.out.println("6 - Child Constructor"); }
11
}
12

13
// First `new Child()` outputs: 1 2 3 4 5 6
14
// Subsequent `new Child()` outputs: 3 4 5 6 (static blocks execute only once)

1
abstract class Base {
2
    Base() { init(); } // Dangerous: Executes before child fields are initialized
3
    abstract void init();
4
}
5

6
class Sub extends Base {
7
    private final String config = loadConfig();
8

9
    @Override
10
    void init() {
11
        System.out.println(config); // Prints null! config has not been assigned yet
12
    }
13
}

3. Method Overloading vs. Overriding#

1
class Animal {
2
    void speak() { System.out.println("..."); }
3
}
4

5
class Dog extends Animal {
6
    @Override
7
    void speak() { System.out.println("Woof"); }
8
}
9

10
Animal a = new Dog();
11
a.speak(); // Output: Woof
12
// Compilation checks the declared reference type (Animal); runtime executes the actual object type (Dog).

Tip: Always use @Override. It forces a compilation error if you misspell a method name, preventing stealthy bugs caused by unintended method overloading.

4. Abstract Classes vs. Interfaces#

Modern interfaces are highly versatile:

1
public interface OrderRepository {
2
    Order findById(Long id); // Abstract method
3

4
    // Java 8+: Default method (implementations are not forced to override this)
5
    default boolean exists(Long id) {
6
        return findById(id) != null;
7
    }
8

9
    // Java 8+: Static utility method
10
    static OrderRepository empty() {
11
        return id -> null;
12
    }
13
}

Selection Guidelines:

• Use an Abstract Class when classes share internal state (fields) or constructor logic.
• Use an Interface when defining capabilities or contracts, or when requiring multiple implementation inheritance.
• Modern Java default: Prefer interfaces paired with default methods for shared utility.

When multiple interfaces contain conflicting default methods, the implementing class must explicitly resolve the conflict:

1
interface A { default void hi() { System.out.println("A"); } }
2
interface B { default void hi() { System.out.println("B"); } }
3

4
class C implements A, B {
5
    @Override
6
    public void hi() {
7
        A.super.hi(); // Explicitly delegates to interface A's implementation
8
    }
9
}

5. The equals and hashCode Contract#

This is one of the most critical structural contracts in Java. Violating it leads to lost data inside collection types like HashMap and HashSet.

The Rule: If two objects are equal according to equals(), their hashCode() values must be identical. If two objects have the same hashCode(), they are not necessarily equal according to equals().

1
class User {
2
    private final Long id;
3
    private final String name;
4

5
    User(Long id, String name) {
6
        this.id = id;
7
        this.name = name;
8
    }
9

10
    @Override
11
    public boolean equals(Object o) {
12
        if (this == o) return true;
13
        if (!(o instanceof User user)) return false; // Java 16+ pattern matching
14
        return Objects.equals(id, user.id) && Objects.equals(name, user.name);
15
    }
16

17
    @Override
18
    public int hashCode() {
19
        return Objects.hash(id, name);
20
    }
21
}

1
Set<User> set = new HashSet<>();
2
set.add(new User(1L, "Tom"));
3

4
System.out.println(set.contains(new User(1L, "Tom"))); // Returns false!
5
// The instances are logically equal via `equals()`, but default hash codes place them in different hash buckets.

6. Records: Concise Data Carriers (Java 16+)#

For classes that exist solely to hold data (such as DTOs, VOs, or configuration objects), hand-writing getters, equals(), hashCode(), and toString() creates unnecessary boilerplate. Java record types reduce this to a single line:

1
public record Order(Long id, String sku, int quantity, long amountInCents) {
2
    // Compact constructor for validation logic
3
    public Order {
4
        if (quantity <= 0) throw new IllegalArgumentException("Quantity must be positive");
5
        if (amountInCents < 0) throw new IllegalArgumentException("Amount cannot be negative");
6
    }
7
}
8

9
// Usage
10
Order o = new Order(1L, "SKU-001", 2, 9900);
11
System.out.println(o.sku());  // "SKU-001" (Accessor naming uses field name directly, e.g., `sku()`, not `getSku()`)
12
System.out.println(o);        // Output: Order[id=1, sku=SKU-001, quantity=2, amountInCents=9900]

Key Characteristics:

• Implicitly final class with private final fields, making instances immutable by default.
• Automatically implements equals(), hashCode(), and toString().
• Can implement interfaces, but cannot extend classes (inherits implicitly from java.lang.Record).
• Supports custom static methods, instance methods, and compact constructors.

Common Applications: API response payloads, DB query projections, compound Map keys, and multi-value returns. Supported natively by Spring Boot 3, Jackson, and modern ORMs.

7. Composition Over Inheritance#

Inheritance introduces tight coupling: changes to a superclass ripple down to all subclasses, and subclasses can breach encapsulation by relying on superclass protected details (Effective Java, Item 18).

Prefer composition (delegation) over inheritance:

1
// ❌ WRONG: Subclassing a third-party class binds you to its internal implementation details
2
class CountingHashSet<E> extends HashSet<E> {
3
    private int addCount = 0;
4

5
    @Override
6
    public boolean add(E e) {
7
        addCount++;
8
        return super.add(e);
9
    }
10
    // If HashSet.addAll internally delegates to add(), your counter will silently double-count!
11
}
12

13
// ✅ RIGHT: Composition + Delegation depends strictly on public contracts
14
class CountingSet<E> implements Set<E> {
15
    private final Set<E> delegate = new HashSet<>();
16
    private int addCount = 0;
17

18
    @Override
19
    public boolean add(E e) {
20
        addCount++;
21
        return delegate.add(e);
22
    }
23
    // Forward all remaining methods to the delegate instance
24
}

When to Use Inheritance:

• There is a clear is-a relationship.
• You own and control the parent class (within the same module).
• The superclass is explicitly designed and documented for extension.

8. Common Traps & Antipatterns#

• Overriding equals() Without hashCode(): Causes duplicate entries in HashSet and failed lookups in HashMap.

• Using Mutable Objects as Map Keys:

  1
  List<String> key = new ArrayList<>(List.of("a"));
  2
  Map<List<String>, String> map = new HashMap<>();
  3
  map.put(key, "value");
  4
  
  5
  key.add("b"); // Modifying key alters its hash code!
  6
  map.get(key); // Returns null!
  

  Fix: Use immutable types like String, Integer, or record for Map keys.

• Unsafe Casting in equals(): Direct casting without instanceof checks raises a ClassCastException. Use Java 16+ pattern matching (o instanceof User user).

• Invoking Overridable Methods in Constructors: Triggers subclass code execution before child field values have been initialized.

• Confusing private Shadowing with Overriding: private methods are hidden from child classes. Defining a method with the same signature in a child class creates an independent method rather than an override, disabling dynamic dispatch.

• Subclassing Merely for Code Reuse: Needing shared methods does not justify an inheritance hierarchy. Use static utilities, composition, or interface default methods instead.