عمیق در OOP: کلاس انتزاعی در برابر اینترفیس و چهار ستونOOP Deep Dive: Abstract vs Interface & the Four Pillars

You have written object-oriented code for five years, but a senior interview is a different arena: they will not ask "what is inheritance." They will drop a snippet in front of you and say "exactly what prints, and why." This chapter takes you from the plain sentences all the way to those subtle traps — and, more importantly, makes you feel the reason behind each behavior instead of memorizing it.

Before anything else, let us build a compass, because nearly every trap in this chapter rotates around a single axis.

Part 0 — words you must feel first

Before diving in, let us unpack three words plainly, because the rest of the chapter leans on them constantly.

• Invariant: a rule an object must hold for its entire lifetime; e.g., "the account balance is never negative." If the object lets that rule break, it is broken.
• Coupling: how much one piece of code depends on the internal details of another. High coupling means changing one breaks the other.
• Dispatch: "which implementation of a method actually runs." When we say dispatch is "dynamic," the decision is made at runtime; "static" means it is locked at compile time.

The Four Pillars

OOP in Java is fundamentally about who knows what and who decides at which moment. Encapsulation controls who knows the internal state; abstraction and polymorphism control when a decision is made. Let us build the pillars one by one.

1. Encapsulation

Encapsulation is bundling data with the code that operates on it and restricting direct access to that data so the object controls its own invariants. It is not "adding getters and setters" — a class with a public setter for every private field is a struct in disguise with no invariant protection. A counter that lets everyone walk off with any drug, no prescription, is no longer a pharmacy.

Back to Java:

public final class Money {
    private final long cents;        // invariant: no fractional cents
    private final String currency;

    public Money(long cents, String currency) {
        this.cents = cents;
        this.currency = Objects.requireNonNull(currency);
    }

    public Money plus(Money other) {
        if (!currency.equals(other.currency))  // invariant enforced here
            throw new IllegalArgumentException("currency mismatch");
        return new Money(this.cents + other.cents, currency);
    }
    // No setters. State transitions produce new instances.
}

The point: callers cannot construct a Money in an inconsistent state, and cannot mutate one into an invalid one. The rule "currencies must match" lives in exactly one place. Real encapsulation is about guarding invariants, immutability being its strongest form — because something that never changes can never drift into a broken state.

2. Inheritance

Inheritance (extends) models an is-a relationship and shares implementation. Java has single class inheritance (one superclass) but multiple interface inheritance. Inheritance is the most abused pillar because it creates the language's tightest coupling: a subclass depends on the implementation of its parent, not just its contract.

abstract class Shape {
    abstract double area();                 // subclass MUST provide
    String describe() {                     // shared implementation
        return getClass().getSimpleName() + " area=" + area();
    }
}
class Circle extends Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    @Override double area() { return Math.PI * r * r; }
}

Here Shape says "every shape has an area but I don't know how to compute it" (the abstract method), yet it provides the shared describe() for everyone. Circle fills in only the missing piece.

3. Polymorphism

"Polymorphism" means "many shapes": one name, many behaviors. But in an interview you must separate its two entirely different kinds, or you will get caught.

• Subtype (runtime) polymorphism: overriding. A Shape reference invokes Circle.area() based on the actual runtime object. This is dynamic dispatch.
• Ad-hoc (compile-time) polymorphism: overloading. Which print(x) runs is chosen by the compiler from the argument's static type.

Shape s = new Circle(2);
System.out.println(s.area());   // 12.56... — dynamic dispatch to Circle

The label on s is Shape, but the JVM opens the box, sees it is really a Circle, and calls Circle's version of area().

4. Abstraction

Abstraction is exposing what an object does while hiding how. Like a car's gas pedal: you know "press it to go faster" without knowing the explosions inside the engine. Abstract classes and interfaces are the two tools — and the rest of this chapter is largely about choosing wisely between them.

Abstract class vs Interface

Both are abstraction mechanisms; they differ in what they can carry and how they compose. Read this table carefully, because each row is a potential interview question:

When to pick which

• Interface when you are defining a capability that unrelated types may have (Comparable, AutoCloseable, Serializable), when a type must participate in multiple hierarchies, or when you want maximum decoupling ("program to interfaces").
• Abstract class when subtypes are genuinely variants of one thing, share fields/constructor logic/state, or need protected helpers and template-method skeletons.
• Rule of thumb: default to interfaces; reach for an abstract class only when you must share mutable state or non-public implementation. Many designs use both — a public interface for the contract and a package-private abstract base for shared plumbing (see AbstractList, AbstractMap in the JDK).

default, static, and private interface methods

Here is a puzzle: if an interface is just a contract with no method bodies, how did Java later add stream() to Collection without breaking the millions of existing classes that already implemented Collection?

Java 8 added default and static methods to interfaces so the platform could evolve interfaces (e.g., adding Collection.stream()) without breaking every implementer. Java 9 added private (and private static) interface methods to share code between default methods without exposing it as part of the public contract.

public interface Discount {
    double rate();                                  // abstract

    default double apply(double price) {            // default — inheritable
        return price * (1 - normalized());          // calls private helper
    }

    static Discount none() { return () -> 0.0; }    // static — not inherited

    private double normalized() {                   // Java 9+, hidden helper
        return Math.max(0, Math.min(1, rate()));
    }
}

Key rules to keep memorized:

• static interface methods are not inherited and must be called on the interface itself (Discount.none()), never on an implementing instance or subinterface.
• default methods are inherited and can be overridden.
• A default method cannot be final, static, or abstract; it has no instance state to touch (interfaces have none) beyond calling abstract methods.

The diamond problem and its resolution

The classic multiple-inheritance ambiguity: two supertypes provide the same default method. Java forbids the ambiguity at compile time and forces you to resolve it explicitly.

interface A { default String hello() { return "A"; } }
interface B { default String hello() { return "B"; } }

class C implements A, B {
    // Compile error WITHOUT this override:
    // "class C inherits unrelated defaults for hello() from A and B"
    @Override public String hello() {
        return A.super.hello() + B.super.hello();   // explicit disambiguation
    }
}

Notice the special syntax A.super.hello() — it is the only way to say "I want boss A's version." Resolution rules, in precedence order:

1. Class wins: a concrete or abstract method from a superclass beats any interface default. ("Class always wins over interface.")
2. Most specific interface wins: if interface D extends A and overrides the default, D's version beats A's.
3. Otherwise you must override and may delegate with Interface.super.method().

Composition over inheritance

Inheritance couples you to a superclass's implementation and breaks encapsulation: overriding one method can silently break another that calls it internally (the fragile base class / self-use problem). Josh Bloch's canonical example is subclassing HashSet to count insertions — but addAll internally calls add, so counts double:

// BROKEN: inheritance leaks the fact that addAll calls add
class CountingSet<E> extends HashSet<E> {
    int count = 0;
    @Override public boolean add(E e) { count++; return super.add(e); }
    @Override public boolean addAll(Collection<? extends E> c) {
        count += c.size();                 // then super.addAll calls add() again!
        return super.addAll(c);            // double counts
    }
}

If you add three elements with addAll, count becomes 6 instead of 3: once c.size() added three, then super.addAll internally called add three times, each counting again. Now the correct version, with composition:

// FIXED: composition — delegate to a held instance, depend only on the Set contract
final class CountingSet<E> implements Set<E> {
    private final Set<E> delegate;
    private int count = 0;
    CountingSet(Set<E> delegate) { this.delegate = delegate; }
    @Override public boolean add(E e) { count++; return delegate.add(e); }
    @Override public boolean addAll(Collection<? extends E> c) {
        count += c.size(); return delegate.addAll(c);  // no leakage: delegate's addAll is opaque
    }
    public int count() { return count; }
    // ... forward remaining Set methods to delegate
}

Composition depends on the interface (Set), not the implementation, so internal self-calls in the delegate are invisible and cannot break you. Prefer inheritance only when there is a genuine is-a relationship and the superclass was deliberately designed and documented for extension.

Static vs dynamic dispatch

Now back to the chapter's compass, sharpened.

• Dynamic dispatch (virtual method invocation): instance methods. The JVM looks up the method in the object's actual-class "vtable" at runtime. (A vtable is simply a per-class table the JVM keeps saying which implementation each method points to.)
• Static dispatch: static methods, private methods, final methods (cannot be overridden), field access, and overload selection. All resolved at compile time from the static type.

class Animal { String noise() { return "?"; } static String kind() { return "Animal"; } }
class Dog extends Animal { @Override String noise() { return "woof"; } static String kind() { return "Dog"; } }

Animal a = new Dog();
System.out.println(a.noise());   // "woof"   — dynamic: actual type Dog
System.out.println(a.kind());    // "Animal" — static: hidden, resolved by static type Animal

Overloading vs overriding

These two words look alike, and that resemblance is the source of countless mistakes. This table spells out the difference line by line:

Rules an overrider must obey (these are the "signature compatibility rules"):

• Return type: covariant — may return a subtype (since Java 5).
• Access modifier: cannot be more restrictive (a public method can't be overridden as protected).
• Checked exceptions: cannot throw new or broader checked exceptions; may throw fewer/narrower or unchecked ones.

Covariant returns

"Covariant" means "moves in the same direction as the hierarchy": because Cat is a subtype of Animal, the override may narrow the return type from Animal to Cat.

class Animal { Animal reproduce() { return new Animal(); } }
class Cat extends Animal {
    @Override Cat reproduce() { return new Cat(); }  // covariant return: Cat <: Animal
}

This is why clone() overrides can return the exact type (instead of a raw Object), and why builder/fluent hierarchies compile cleanly.

final and sealed

• final class: cannot be subclassed (String, Integer). Enables optimizations and guarantees no override-based invariant breakage.
• final method: cannot be overridden; the call is statically dispatched.
• final field: assigned once; the basis of safe publication and immutability.
• sealed (finalized in Java 17): a class or interface restricts, via the permits keyword, exactly which types may extend or implement it. Permitted subtypes must themselves be final, sealed, or non-sealed, and must be in the same module (or the same package if in an unnamed module).

public sealed interface Shape permits Circle, Rectangle {}
public final class Circle implements Shape { /* ... */ }
public non-sealed class Rectangle implements Shape {}  // reopens the hierarchy

Sealing gives you a closed set of subtypes, which makes exhaustive switch pattern matching possible without a default branch — because the compiler knows all possible cases. It is the enabling feature for algebraic-data-type-style modeling and lets the compiler verify exhaustiveness:

double area(Shape s) {
    return switch (s) {                 // no default needed — Shape is sealed
        case Circle c    -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.w() * r.h();
    };
}

The Liskov angle

The Liskov Substitution Principle (LSP): objects of a subtype must be substitutable for the supertype without altering correctness. Java's type system enforces the signature part (covariant returns, no narrower access, no broader checked exceptions) but cannot enforce the behavioral part — that is on you:

• Preconditions may not be strengthened by a subtype ("don't demand more than the parent").
• Postconditions may not be weakened ("don't deliver less than the parent").
• Invariants of the supertype must be preserved.
• History constraint: a subtype must not allow state changes the supertype forbids. (This is why a mutable Point3D subclass of an immutable Point is a classic violation: the parent promised "I never change," and the child broke that promise.)

The canonical violation is Square extends Rectangle: if Rectangle.setWidth is expected to leave height unchanged, a Square that couples width and height breaks any code relying on that postcondition. The fix is usually composition or a shared abstraction, not inheritance.

Common pitfalls & gotchas

Interview Questions

Now it is game time. Answer each yourself first, then unfold the answer.

class A { int x = 1; int get() { return x; } }
class B extends A { int x = 2; int get() { return x; } }
A a = new B();
System.out.println(a.x + " " + a.get());

class Base { Base() { init(); } void init() { System.out.println("base"); } }
class Sub extends Base {
    String msg = "hello";
    @Override void init() { System.out.println(msg); }
}
new Sub();

void f(Object o) { System.out.println("Object"); }
void f(int... i)  { System.out.println("varargs"); }
f(1);

interface I { default String who() { return "I"; } }
class P { public String who() { return "P"; } }
class Q extends P implements I { }
new Q().who();

class A { static String s() { return "A"; } }
class B extends A { static String s() { return "B"; } }
A ref = new B();
System.out.println(ref.s());

Senior notes & advanced edge cases

The chapter above gave you the mechanics: static vs dynamic type, the four pillars, the diamond, Liskov. Senior level is where those mechanics collide with the JVM's internals, with library evolution over years, and with the modern Java (records, pattern matching, sealed ADTs) that reshaped this whole topic. Everything here is additive — the traps and facts the first pass deliberately left on the table.

1. Records — what Money was really reaching for

That hand-written Money from the chapter (final fields, no setters, an equals you must write yourself) is exactly the pattern Java 16 turned into a keyword: the record. A record is an immutable data carrier for which the compiler auto-generates the canonical constructor, accessors, and mutually-consistent equals/hashCode/toString.

public record Money(long cents, String currency) {
    public Money {                              // compact constructor — the canonical body
        Objects.requireNonNull(currency);
        if (cents < 0) throw new IllegalArgumentException("negative");
        // no need for this.cents = cents; the compiler assigns after this block
    }
    public Money plus(Money o) {
        if (!currency.equals(o.currency)) throw new IllegalArgumentException("mismatch");
        return new Money(cents + o.cents, currency);
    }
}

A senior fact many miss: a record is safer for invariants than an ordinary Serializable class. When you deserialize a normal class, the JVM builds the object without calling any constructor and pours the bytes straight onto the fields — so an attacker can craft an "impossible" object (say cents = -100) that would never have passed the constructor. Record deserialization, by contrast, always goes through the canonical constructor, so that same if (cents < 0) runs again. That is a real security win.

public record Trade(String sym, int[] lots) {
    public Trade {                       // copy on the way in
        lots = lots.clone();
    }
    public int[] lots() {                // copy on the way out
        return lots.clone();
    }
}

A record cannot extends another class (it implicitly extends Record and is final), but it can implement interfaces. That is what makes record + sealed a clean algebraic data type (ADT): one sealed interface and several record subtypes — exactly the Shape/Circle/Rectangle shape from the chapter, except every case is now a full, auto-generated data carrier.

2. The equals + inheritance impossibility (Effective Java, Item 10)

The chapter said equals cannot be a default in an interface. The deeper, classic interview trap is this: you cannot extend an instantiable class, add a new "value component," and still keep the equals contract intact. This is not a style preference; it is a mathematical impossibility.

Take Point(x, y) with an instanceof-based equals, and extend it as ColorPoint(x, y, color):

• If ColorPoint.equals also checks color, symmetry breaks: point.equals(colorPoint) is true (because Point.equals never sees color) but colorPoint.equals(point) is false.
• If you "fix" symmetry by making ColorPoint.equals ignore color when the other side is a plain Point, transitivity breaks: a red and a blue ColorPoint are each equal to one white Point, yet not equal to each other.

This is precisely why records are safe here: a record is inherently final, so a value-component-adding subtype cannot exist and the whole trap is moot.

3. How dispatch really works: bytecode + JIT

The chapter said instance methods dispatch "dynamically" and the rest "statically." A real senior knows the four (plus one) opcodes behind that:

The key insight: a call through an interface (invokeinterface) is inherently costlier than a call through a class (invokevirtual), because a class can implement several interfaces in different layouts, so a simple fixed-index vtable is not enough and the JVM must consult an itable. In hot loops this difference is measurable.

State of a call site — the lifecycle of a virtual call as the JIT sees it:

stateDiagram-v2
    [*] --> Unlinked
    Unlinked --> Monomorphic: first type seen
    Monomorphic --> Bimorphic: 2nd type seen
    Bimorphic --> Megamorphic: 3rd+ types
    Monomorphic --> Inlined: JIT + CHA
    Megamorphic --> VtableLookup: cache busted

4. Bridge methods

You see these in javap but never wrote them in source. Because of generics erasure, the compiler sometimes emits a synthetic method called a bridge to keep polymorphism intact:

class Node<T> { public void set(T t) { } }
class IntNode extends Node<Integer> {
    public void set(Integer i) { }              // you think this overrides
}

After erasure the parent's signature is set(Object) but the child has set(Integer) — left as is, Node<Integer> n = new IntNode(); n.set(5); would not reach the override. So the compiler generates a synthetic bridge set(Object o) { set((Integer)o); } in IntNode. A covariant return creates a bridge the same way (an Object-returning version delegating to the real narrowed one).

5. The package-private "override" trap

The chapter said an override cannot narrow the access modifier. The more dangerous trap is this: a package-private (no-modifier) method is simply NOT overridden by a subclass in a different package — even if the signature matches exactly. They are two entirely separate methods, and dynamic dispatch does not connect them.

// package a
public class Base {
    void hook() { System.out.println("base"); }     // package-private
    public void run() { hook(); }
}
// package b
public class Sub extends a.Base {
    void hook() { System.out.println("sub"); }       // NOT an override!
}

Calling new b.Sub().run() prints base, not sub — because Base.run() is bound to Base.hook(), and Sub.hook(), being in a different package, is not even considered the same method. Put @Override on Sub.hook() and it won't compile. This bug really burns people in cross-package template-method designs (or in tests that try to override a hook).

6. Re-abstraction and the silent "class wins" hazard

Two subtleties that follow directly from the default-methods discussion:

Re-abstraction: a subinterface can re-declare a parent's default method as abstract, stripping the implementation and forcing implementers to provide their own:

interface A { default String id() { return "A"; } }
interface B extends A { String id(); }   // abstract again — any B implementer must define id

7. Pattern matching for switch, deeply (Java 21)

The chapter showed that sealed makes a switch exhaustive without a default. Java 21 pushed this much further: record deconstruction patterns and guarded patterns with when.

sealed interface Shape permits Circle, Rectangle {}
record Circle(double r) implements Shape {}
record Rectangle(double w, double h) implements Shape {}

String describe(Shape s) {
    return switch (s) {
        case Circle(double r) when r > 100 -> "huge circle";  // guard
        case Circle(double r)              -> "circle " + r;   // deconstructs the component
        case Rectangle(double w, double h) -> "rect " + (w * h);
    };                                                          // no default — it's exhaustive
}

8. Initialization order and safe publication

The chapter showed the "calling an overridable method from a constructor" trap. The full order behind it is itself an interview question. For new Sub():

1. static blocks/fields (parent first, then child) — once per program lifetime, at class load.
2. super(...) up the chain; at each level: that level's instance initializers and instance blocks, then that level's constructor body.
3. Then the child's field initializers and instance blocks run — and only then the child's constructor body. That is exactly why, in the constructor trap, msg was still null.

9. Value-based classes and the Valhalla horizon

Java has types marked @jdk.internal.ValueBased: the wrappers (Integer, Long…), Optional, and most of java.time such as LocalDate. These have no identity; only their value matters, and they must be compared with .equals().

Senior interview questions

// package a
public class Base { void hook(){System.out.print("base");} public void run(){hook();} }
// package b
public class Sub extends a.Base { void hook(){System.out.print("sub");} }
// elsewhere: new b.Sub().run();

sealed interface S permits X, Y {} record X(int a) implements S {} record Y(int b) implements S {}
String f(S s){ return switch(s){ case X x -> "x"; case X(int a) when a>0 -> "pos"; case Y y -> "y"; }; }

case X(int a) when a>0 -> "pos";
case X x               -> "x";