Object-Oriented Programming in Java

Inheritance (extends) creates an "is-a" relationship: a Car is a Vehicle. The subclass automatically gets (and is coupled to) the superclass's implementation, including any future changes to it — this is the classic fragile base class problem: a seemingly safe change to a superclass can silently break subclasses.

Composition creates a "has-a" relationship: a Car has an Engine. Instead of inheriting behavior, the object holds a reference to another object and delegates to it:

// Inheritance (tightly coupled, fixed at compile time)
class ElectricCar extends Car { }

// Composition (flexible, swappable at runtime)
class Car {
    private final Engine engine; // interface type
    Car(Engine engine) { this.engine = engine; }
    void start() { engine.start(); }
}
class ElectricEngine implements Engine { public void start() { /* ... */ } }

Why composition is often favored ("favor composition over inheritance"):

• Looser coupling — the containing class depends only on an interface, not a concrete superclass's internals.
• Runtime flexibility — you can swap the Engine implementation via constructor injection; inheritance locks the relationship at compile time.
• Avoids deep, fragile hierarchies — no diamond-shaped confusion, no accidental overrides breaking behavior.
• Respects encapsulation — a class doesn't expose (or inherit) implementation details it doesn't need.

Inheritance still earns its place for genuine "is-a" hierarchies with strong behavioral substitutability (Liskov Substitution Principle) — e.g., Circle/Rectangle extending Shape — but composition is usually the safer default for code reuse.

Before Java 8, adding a new method to an interface broke every class implementing it (a compile error for missing implementations). Default methods solve this by letting an interface provide a body that implementers inherit automatically:

interface Vehicle {
    void drive();
    default void honk() { System.out.println("Beep!"); } // inherited by default
}
class Car implements Vehicle {
    public void drive() { /* ... */ } // honk() comes for free
}

A class can still override a default method if it needs different behavior. If a class implements two interfaces with clashing default methods, the compiler forces it to explicitly resolve the conflict by overriding the method itself.

Static interface methods belong to the interface type, not to instances, and are called like InterfaceName.method() — used for factory/helper methods related to the interface (e.g., Comparator.comparing(...), List.of(...)):

interface MathOps {
    static int square(int x) { return x * x; }
}
MathOps.square(5); // 25

The main motivation was API evolution: default methods let the JDK retrofit Collection/List/Map with forEach, stream, removeIf, getOrDefault, etc., in Java 8 without breaking the huge ecosystem of existing implementations — a form of controlled, backward-compatible multiple inheritance of behavior (not state).

Java has four flavors of classes defined inside another class:

1. Static nested class: declared static inside another class; behaves like a regular top-level class namespaced under the outer one, with no implicit reference to an outer instance.

class Outer {
    static class Nested { }
}
Outer.Nested n = new Outer.Nested();

1. Inner class (non-static): each instance is tied to an enclosing Outer instance and can access its fields/methods directly (holds an implicit Outer.this reference).

class Outer {
    int x = 5;
    class Inner { int getX() { return x; } }
}
Outer o = new Outer();
Outer.Inner in = o.new Inner();

1. Local class: defined inside a method body; visible only within that method, and can capture effectively-final local variables from the enclosing scope.

void process() {
    class Helper { void run() { /* ... */ } }
    new Helper().run();
}

1. Anonymous class: a local class without a name, declared and instantiated in a single expression — commonly used to implement an interface or extend a class inline (before lambdas covered the single-abstract-method case).

Runnable r = new Runnable() {
    @Override public void run() { System.out.println("running"); }
};

When to use which: static nested for a helper type that doesn't need outer state (e.g., Map.Entry); inner for a type conceptually tied to an outer instance (e.g., an Iterator over a custom collection); local/anonymous for short-lived, one-off implementations — though lambdas have replaced most anonymous-class use cases for functional interfaces since Java 8.

A marker interface declares no methods at all — implementing it adds no new behavior directly, but signals to the JVM or a library that instances of the class should be treated specially.

Classic JDK examples:

• Serializable: marks a class as eligible for Java serialization; ObjectOutputStream checks instanceof Serializable before writing an object, throwing NotSerializableException otherwise.
• Cloneable: marks a class as allowing Object.clone() to succeed; without it, calling clone() throws CloneNotSupportedException.
• RandomAccess: marks a List implementation (like ArrayList) as supporting fast, O(1) indexed access, letting algorithms (e.g., Collections.binarySearch) choose an index-based loop instead of an iterator-based one for better performance.

class Point implements Serializable {
    int x, y; // now writable via ObjectOutputStream
}

Why they exist: before annotations (Java 5), tagging a class for special treatment required some type-level mechanism checkable via instanceof — an interface with no members was the idiom.

Modern alternative: annotations (@Deprecated, @FunctionalInterface, or custom ones processed via reflection) are now generally preferred for new APIs, since they can carry additional metadata (values, targets, retention) that a bare marker interface can't. Marker interfaces persist mainly for backward compatibility and cases (like Serializable) baked deeply into the platform.

Before records, a simple immutable data holder required a lot of repetitive, error-prone boilerplate: private final fields, a constructor, getters, and manually-written equals()/hashCode()/toString() — easy to get subtly wrong (e.g., forgetting a field in equals()).

A record (finalized in Java 16) collapses all of that into one declaration:

record Point(int x, int y) { }

This single line generates:

• private final int x; private final int y;
• A canonical constructor Point(int x, int y)
• Accessor methods x() and y() (not getX() — no "get" prefix)
• Correct, component-based equals(), hashCode(), and toString()

Records can still have additional methods, static members, and a compact constructor for validation:

record Range(int min, int max) {
    Range { // compact constructor — validates before fields are assigned
        if (min > max) throw new IllegalArgumentException("min > max");
    }
    int length() { return max - min; }
}

Constraints: all fields are implicitly private final, a record cannot extend another class (it implicitly extends Record), and it cannot declare additional instance fields beyond its components. Records are ideal for DTOs, value objects, and API response/request shapes — anywhere you want a transparent, immutable carrier of data without hand-rolling boilerplate.

Normally, any class can be subclassed (unless final) by anyone, anywhere. Sealed classes/interfaces (standardized in Java 17) let a type declare exactly which classes are allowed to extend/implement it, via permits:

sealed interface Shape permits Circle, Square, Rectangle { }

final class Circle implements Shape { double radius; }
final class Square implements Shape { double side; }
non-sealed class Rectangle implements Shape { double w, h; } // opens this branch back up

Each permitted subtype must itself be declared final (no further subtyping), sealed (continues restricting), or non-sealed (reopens unrestricted extension) — this forces every branch of the hierarchy to make an explicit choice.

Why use it: it models a closed, known set of variants — similar to algebraic data types / enums-with-data in other languages — while keeping normal class-based polymorphism. Combined with pattern matching for switch (finalized in Java 21, preview earlier), the compiler can verify a switch over a sealed type covers every permitted subtype, catching missing cases at compile time instead of via a runtime default:

double area(Shape s) {
    return switch (s) {
        case Circle c -> Math.PI * c.radius * c.radius;
        case Square sq -> sq.side * sq.side;
        case Rectangle r -> r.w * r.h;
        // no `default` needed — compiler proves exhaustiveness
    };
}

This is especially useful for domain models where you deliberately want to prevent uncontrolled extension (e.g., a fixed set of event types, request results, or expression-tree nodes).

The classic "diamond problem" happens when a class inherits the same method signature from two different sources that each provide a default implementation, and it's ambiguous which one should apply. In Java, this can only arise through default methods on interfaces (since classes only support single inheritance, and abstract methods without bodies never conflict):

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

class C implements A, B {
    // compile error unless C overrides name() explicitly
}

Java doesn't guess — it forces the implementing class to resolve the conflict explicitly by overriding the method, optionally delegating to one of the parent interfaces using InterfaceName.super.method():

class C implements A, B {
    @Override
    public String name() {
        return A.super.name() + B.super.name(); // explicit choice
    }
}

If a class extends both a concrete superclass and implements an interface with a default method of the same signature, the class (superclass) implementation always wins — "class wins over interface" is one of Java's tie-breaking rules, so no ambiguity error is raised in that specific case.

This design avoids the classic C++ diamond-inheritance ambiguity around state entirely (Java still forbids multiple inheritance of instance fields/constructors), while allowing controlled multiple inheritance of behavior through default methods.