Leaky Abstractions in Java — Why Interface Swaps Break

// Abstract class: partially implemented blueprint
// Notice we define the 'what' (calculateArea) but also provide shared behaviour (describe)
abstract class Shape {
    private String colour;

    public Shape(String colour) {
        this.colour = colour;
    }

    // Abstract method — subclasses MUST implement this
    // We know every shape HAS an area, but we can't compute it here
    public abstract double calculateArea();

    // Concrete method — shared behaviour all shapes can use as-is
    public void describe() {
        System.out.println("I am a " + colour + " shape with area: " + calculateArea());
    }
}

class Circle extends Shape {
    private double radius;

    public Circle(String colour, double radius) {
        super(colour);         // passes colour up to the abstract class
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;  // Circle-specific formula hidden from caller
    }
}

class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(String colour, double width, double height) {
        super(colour);
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea() {
        return width * height;  // Rectangle-specific formula
    }
}

public class AbstractionBasics {
    public static void main(String[] args) {
        // We talk to Shape — we don't care which kind at call time
        Shape circle = new Circle("red", 5.0);
        Shape rectangle = new Rectangle("blue", 4.0, 6.0);

        circle.describe();     // calls Circle's calculateArea() under the hood
        rectangle.describe();  // calls Rectangle's calculateArea() under the hood
    }
}

// Interface: a pure contract for payment processing
// Any class implementing this PROMISES to provide these methods
interface PaymentProcessor {
    boolean processPayment(String customerId, double amount);
    void refundPayment(String transactionId);

    // Default method (Java 8+) — provides fallback behaviour
    // Implementing classes can override this, but don't have to
    default String getCurrencySymbol() {
        return "$";  // sensible default most processors will use
    }
}

// Stripe implementation — the HOW is completely hidden from callers
class StripeProcessor implements PaymentProcessor {
    @Override
    public boolean processPayment(String customerId, double amount) {
        // In real life: API call to Stripe here
        System.out.println("[Stripe] Charging " + customerId + " for $" + amount);
        return true;  // assume success for this demo
    }

    @Override
    public void refundPayment(String transactionId) {
        System.out.println("[Stripe] Refunding transaction: " + transactionId);
    }
}

// PayPal implementation — same contract, completely different internals
class PayPalProcessor implements PaymentProcessor {
    @Override
    public boolean processPayment(String customerId, double amount) {
        // In real life: PayPal SDK call here
        System.out.println("[PayPal] Billing " + customerId + " for $" + amount);
        return true;
    }

    @Override
    public void refundPayment(String transactionId) {
        System.out.println("[PayPal] Reversing transaction: " + transactionId);
    }

    @Override
    public String getCurrencySymbol() {
        return "USD ";  // PayPal uses a different display format
    }
}

// CheckoutService depends on the INTERFACE, not any specific processor
// Swap Stripe for PayPal by changing ONE line in your config — nothing else changes
class CheckoutService {
    private final PaymentProcessor paymentProcessor;

    // Injected at construction time — the service doesn't choose its processor
    public CheckoutService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }

    public void checkout(String customerId, double cartTotal) {
        System.out.println("Processing checkout for customer: " + customerId);
        boolean success = paymentProcessor.processPayment(customerId, cartTotal);
        if (success) {
            System.out.println("Payment of " + paymentProcessor.getCurrencySymbol() + cartTotal + " confirmed.");
        }
    }
}

public class PaymentSystem {
    public static void main(String[] args) {
        // Switch between processors without touching CheckoutService at all
        CheckoutService stripeCheckout = new CheckoutService(new StripeProcessor());
        stripeCheckout.checkout("cust_001", 99.99);

        System.out.println("--- Switching to PayPal ---");

        CheckoutService paypalCheckout = new CheckoutService(new PayPalProcessor());
        paypalCheckout.checkout("cust_001", 99.99);
    }
}

// INTERFACE: defines the contract — what every notifier must do
interface Notifier {
    void sendNotification(String recipient, String message);
    boolean isAvailable();  // can this channel currently send?
}

// ABSTRACT CLASS: implements the interface and provides shared plumbing
// Avoids repeating the retry logic and logging in every concrete class
abstract class BaseNotifier implements Notifier {
    private final int maxRetries;

    public BaseNotifier(int maxRetries) {
        this.maxRetries = maxRetries;
    }

    // Template method: defines the algorithm skeleton
    // Subclasses customise the 'how', not the 'when'
    public void sendWithRetry(String recipient, String message) {
        int attempt = 0;
        while (attempt < maxRetries) {
            if (isAvailable()) {
                sendNotification(recipient, message);
                System.out.println("[BaseNotifier] Sent on attempt " + (attempt + 1));
                return;  // success — stop retrying
            }
            attempt++;
            System.out.println("[BaseNotifier] Channel unavailable, retry " + attempt + "/" + maxRetries);
        }
        System.out.println("[BaseNotifier] Failed after " + maxRetries + " attempts.");
    }
}

// CONCRETE CLASS: fills in the specifics for email
class EmailNotifier extends BaseNotifier {
    private final String smtpServer;
    private boolean serverOnline;

    public EmailNotifier(String smtpServer, boolean serverOnline) {
        super(3);  // email gets 3 retry attempts
        this.smtpServer = smtpServer;
        this.serverOnline = serverOnline;
    }

    @Override
    public void sendNotification(String recipient, String message) {
        // In reality: JavaMail API call here
        System.out.println("[Email via " + smtpServer + "] To: " + recipient + " — " + message);
    }

    @Override
    public boolean isAvailable() {
        return serverOnline;  // could check real SMTP connection here
    }
}

// CONCRETE CLASS: fills in the specifics for SMS — completely different internals
class SmsNotifier extends BaseNotifier {
    private final String apiKey;

    public SmsNotifier(String apiKey) {
        super(2);  // SMS gets 2 retry attempts
        this.apiKey = apiKey;
    }

    @Override
    public void sendNotification(String recipient, String message) {
        System.out.println("[SMS apiKey=" + apiKey + "] To: " + recipient + " — " + message);
    }

    @Override
    public boolean isAvailable() {
        return true;  // assume SMS gateway is always up
    }
}

public class NotificationSystem {
    public static void main(String[] args) {
        // Email server is down — watch retry logic kick in
        BaseNotifier emailNotifier = new EmailNotifier("smtp.company.com", false);
        emailNotifier.sendWithRetry("alice@example.com", "Your order shipped!");

        System.out.println();

        // SMS is up — sends first time
        BaseNotifier smsNotifier = new SmsNotifier("key_abc123");
        smsNotifier.sendWithRetry("+1-555-0100", "Your order shipped!");
    }
}

// ============================================================
// GOTCHA 1: Leaking implementation details through the interface
// ============================================================

// BAD: This interface is supposed to abstract storage, but it exposes
// SQL-specific concepts — every caller now knows you're using SQL
interface BadUserRepository {
    String findBySqlQuery(String sqlQuery);  // LEAKS implementation detail!
    void executeRawStatement(String sql);    // Even worse
}

// GOOD: The interface talks in business concepts only
// The SQL lives entirely inside the concrete class
interface UserRepository {
    String findById(String userId);        // clean, technology-agnostic
    void save(String userId, String name); // caller doesn't know it's SQL or NoSQL
}

class PostgresUserRepository implements UserRepository {
    @Override
    public String findById(String userId) {
        // In reality: "SELECT * FROM users WHERE id = ?" — caller never sees this
        System.out.println("[Postgres] SELECT WHERE id = " + userId);
        return "Alice";
    }

    @Override
    public void save(String userId, String name) {
        System.out.println("[Postgres] INSERT INTO users VALUES (" + userId + ", " + name + ")");
    }
}

// ============================================================
// GOTCHA 2: Instantiating an abstract class (compile error)
// ============================================================
abstract class Animal {
    public abstract void makeSound();
}

// This line causes a compile error: 'Animal is abstract; cannot be instantiated'
// Animal animal = new Animal();  <-- DON'T DO THIS

// Correct: instantiate a concrete subclass, hold as the abstract type
class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}

public class AbstractionGotchas {
    public static void main(String[] args) {
        // Correct usage: reference type is abstract/interface, object is concrete
        Animal myDog = new Dog();  // Animal reference, Dog object
        myDog.makeSound();

        UserRepository repo = new PostgresUserRepository();
        System.out.println("Found user: " + repo.findById("usr_42"));
        repo.save("usr_43", "Bob");
    }
}