Abstraction Design

In one line

Choosing the right abstraction — interface vs abstract class vs concrete class — and the two patterns that power most LLD answers (strategy and factory).

0/5 · 0%

Think of it like this

A power socket. The socket is the interface: anything with the right plug works, whether it's a phone charger or a fan. You don't rewire the wall when you buy a new appliance.

Key ideas

01
interface: pure contract, a class can implement many, no instance state (default methods allowed since Java 8). Prefer for 'pluggable behaviour'.
02
abstract class: shared state/helpers + a partial template. Use when subclasses genuinely share implementation.
03
concrete class: complete implementation. Start here; introduce abstractions on demand.
04
strategy: capture a family of algorithms behind one interface, select at runtime (pricing rules, payment methods, matching strategies).
05
factory: centralize object creation so callers depend on the result, not the constructor logic.
06
Design skill grade: knowing when NOT to abstract is seniority. 'Composition + strategy + factory' covers 90% of LLD needs.

Java / Spring map

→
Spring stereotypes: interface = port (@Service interface), abstract class rarely needed, concrete = implementation.
→
A classic: Repository interface + JpaRepository impl + InMemoryRepository impl for tests → DIP + strategy.

Code & diagrams

AbstractInterface.javajava

Abstraction ladder: concrete → abstract → interface, and when each is right.

public interface ParkingPricing {      // strategy contract
  double cost(ParkingTicket t);
}

// abstract class: shared template, subclasses fill in the slot
public abstract class BasePricing implements ParkingPricing {
  protected abstract double hourlyRate();
  public double cost(ParkingTicket t) { return hourlyRate() * t.minutes() / 60.0; }
}

// concrete strategy
public class AirportPricing extends BasePricing {
  protected double hourlyRate() { return 4.0; }   // only the "slot" changes
}

// factory: callers never see constructors
public final class PricingFactory {
  public static ParkingPricing forZone(String zone) {
    return switch (zone) {
      case "airport" -> new AirportPricing();
      case "mall"    -> new MallPricing();
      default        -> new StreetPricing();
    };
  }
}

Explain without notes

Why is an interface with 8 methods probably violating Interface Segregation?

When would you keep a concrete class and skip the interface entirely?

Practice

Design pricing for: hourly, monthly, VIP, event-day surge. Show the strategy + factory and where each new type lands.

Trade-offs

↔
One more interface = one more indirection. Add abstraction when variation is real, not imagined.

Completion checklist

I know exactly when I would pick interface vs abstract class for a new variation.

Back to phase

Command Palette