Interfaces & Abstract Classes

public abstract class Animal {
    protected String name;  // shared state
    public Animal(String name) { this.name = name; }  // constructor
    public abstract void makeSound();  // abstract method, subclasses must implement
    public void sleep() { System.out.println(name + " is sleeping"); }  // shared concrete behavior
}

public interface Swimmer {
    void swim();  // contract, no shared state or constructor
}

public class Duck extends Animal implements Swimmer {  // single inheritance + multiple interface implementation
    public Duck(String name) { super(name); }
    public void makeSound() { System.out.println("Quack"); }
    public void swim() { System.out.println(name + " is swimming"); }
}

Common follow-ups: Can an interface have constructors or instance fields with actual mutable state, given it can't have instance fields the way an abstract class can?;What changed about interfaces starting in Java 8 that blurred some of this traditional distinction?

public interface Vehicle {
    void move();

    default void honk() {  // added in a later version WITHOUT breaking existing implementers
        System.out.println("Beep!");
    }
}

public class Car implements Vehicle {
    public void move() { System.out.println("Driving"); }
    // honk() is inherited automatically -- Car doesn't need to implement it, and compiles fine
}

Common follow-ups: What happens if a class implements two interfaces that both provide a default method with the identical signature -- how is the conflict resolved?;Can a default method access the implementing class's own private fields?

public interface A { default void greet() { System.out.println("Hello from A"); } }
public interface B { default void greet() { System.out.println("Hello from B"); } }

public class C implements A, B {
    // MUST override greet() explicitly -- compiler can't choose between A and B's versions
    @Override
    public void greet() {
        A.super.greet();  // explicitly choose A's version (or B's, or provide entirely new logic)
    }
}

Common follow-ups: How does this differ from the classic C++ 'diamond problem' with multiple class inheritance, which Java's single-class-inheritance design was originally intended to avoid entirely?;What happens if interface A extends interface B, and both declare the same default method -- does the compiler still force explicit resolution?

public interface Comparator<T> {
    int compare(T a, T b);

    static <T extends Comparable<T>> Comparator<T> naturalOrder() {  // static factory method
        return Comparable::compareTo;
    }
}

Comparator<String> cmp = Comparator.naturalOrder();  // called via the interface name, NOT inherited by implementers
// cmp.naturalOrder() would NOT work if cmp were some implementing class instance -- it's not inherited

Common follow-ups: Why doesn't a static interface method get inherited by implementing classes, unlike a default method?;What access modifier can interface static methods have, and has this changed across Java versions?

public interface Validator {
    default boolean isValidEmail(String email) {
        return matches(email, "email-pattern") && !isEmpty(email);
    }
    default boolean isValidPhone(String phone) {
        return matches(phone, "phone-pattern") && !isEmpty(phone);
    }

    private boolean isEmpty(String s) {  // shared helper, NOT part of the public interface contract
        return s == null || s.isBlank();
    }
    private boolean matches(String s, String patternKey) {  // shared helper
        return true;  // simplified
    }
}

Common follow-ups: Why weren't private interface methods included in the original Java 8 default methods feature, requiring a separate Java 9 addition?;Can a private interface method be called from an implementing class's own code, or only from within the interface's own default/static methods?

public abstract class ReportGenerator {
    public final void generate() {  // fixed algorithm, cannot be overridden since it's final
        String data = fetchData();
        String formatted = formatData(data);
        saveReport(formatted);
    }
    protected abstract String fetchData();      // subclasses MUST implement
    protected abstract String formatData(String data);  // subclasses MUST implement
    protected void saveReport(String content) { System.out.println("Saving: " + content); }  // shared default behavior
}

Common follow-ups: Why couldn't this exact same guarantee be achieved using an interface with default methods instead of an abstract class?;What's the risk of NOT marking the template method as final, even in an abstract class?

// Classic marker interface approach
public class User implements Serializable { }  // tagged via 'implements', checked with instanceof

// Modern annotation-based tagging alternative
@Retention(RetentionPolicy.RUNTIME)
public @interface Cacheable { }

@Cacheable
public class Product { }
// Checked via reflection: someClass.isAnnotationPresent(Cacheable.class)

Common follow-ups: What specific compile-time enforcement advantage does a marker interface have over an annotation, given generic bounds can require implementing a marker interface?;Why did Java's original serialization mechanism choose a marker interface (Serializable) rather than requiring an annotation, given annotations didn't exist yet at that point in Java's history?

public interface Readable { void read(); }
public interface Writable { void write(); }
public interface ReadWritable extends Readable, Writable {  // extends BOTH simultaneously
    default void readAndWrite() {
        read();
        write();
    }
}

public class File implements ReadWritable {
    public void read() { System.out.println("Reading"); }
    public void write() { System.out.println("Writing"); }
    // readAndWrite() inherited automatically from ReadWritable
}

Common follow-ups: Why doesn't interface multiple inheritance suffer from the same diamond problem that motivated disallowing multiple class inheritance?;How many interfaces can a single interface or class extend/implement -- is there a practical or enforced limit?

public sealed interface Shape permits Circle, Square, Triangle {}

public record Circle(double radius) implements Shape {}
public record Square(double side) implements Shape {}
public record Triangle(double base, double height) implements Shape {}

double area(Shape shape) {
    return switch (shape) {  // exhaustive, no default needed -- compiler verifies ALL permitted types are covered
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Square s -> s.side() * s.side();
        case Triangle t -> 0.5 * t.base() * t.height();
    };
}

Common follow-ups: Why must permitted subclasses of a sealed interface each explicitly declare themselves as final, sealed, or non-sealed?;How does sealing an interface affect a library's ability to be extended by external, third-party consumers?

public abstract class Shape {
    protected final String name;

    protected Shape(String name) {  // protected: intended only to be called by subclasses via super()
        this.name = name;
    }

    public abstract double area();
}

public class Circle extends Shape {
    private final double radius;
    public Circle(double radius) {
        super("Circle");  // calling the protected constructor from a subclass
        this.radius = radius;
    }
    public double area() { return Math.PI * radius * radius; }
}

Common follow-ups: Given the compiler already prevents direct instantiation of an abstract class, what practical difference does the constructor's access modifier actually make?;How does this protected-constructor convention relate to the broader API design principle of clearly signaling intended usage patterns?