Interfaces & Abstraction Best Practices

// "abstract" means: this class describes an idea, not a real thing.
// You can never write  new Payment(...)  — a Payment is too vague to exist.
// Subclasses fill in the missing detail (the abstract method) to become concrete.
abstract class Payment {
    protected double amount;

    Payment(double amount) { this.amount = amount; }

    // ABSTRACT method: no body. Every concrete subclass MUST supply one.
    abstract String authorize();

    // CONCRETE method: shared by all subclasses, written once here.
    void receipt() {
        System.out.println("  Receipt: $" + String.format("%.2f", amount)
            + " via " + authorize());
    }
}

// Concrete subclass: fills in authorize(), so it CAN be instantiated.
class CardPayment extends Payment {
    CardPayment(double amount) { super(amount); }
    String authorize() { return "card (3-D Secure)"; }
}

class CashPayment extends Payment {
    CashPayment(double amount) { super(amount); }
    String authorize() { return "cash (no network)"; }
}

public class Main {
    public static void main(String[] args) {
        // Payment p = new Payment(10);  // ❌ won't compile: Payment is abstract
        Payment[] payments = { new CardPayment(49.99), new CashPayment(5.00) };
        for (Payment p : payments) {
            p.receipt();  // calls the SHARED method; it dispatches to each authorize()
        }
    }
}

  Receipt: $49.99 via card (3-D Secure)
  Receipt: $5.00 via cash (no network)

import java.util.List;

// The ABSTRACTION: what a notifier does, not how. This is the "contract".
interface Notifier {
    void send(String message);
}

// Two interchangeable implementations. The rest of the app never names these.
class EmailNotifier implements Notifier {
    public void send(String message) {
        System.out.println("  email -> " + message);
    }
}
class SmsNotifier implements Notifier {
    public void send(String message) {
        System.out.println("  sms   -> " + message);
    }
}

public class Main {
    // This method depends on the ABSTRACTION (Notifier), not a concrete class.
    // Pass it ANY notifier and it just works — that's polymorphism through
    // abstraction. New notifier types need ZERO changes here.
    static void alertAll(List<Notifier> notifiers, String message) {
        for (Notifier n : notifiers) {
            n.send(message);  // each one behaves differently behind one contract
        }
    }

    public static void main(String[] args) {
        // Program to the INTERFACE on the left, choose the implementation on the right.
        List<Notifier> notifiers = List.of(new EmailNotifier(), new SmsNotifier());
        alertAll(notifiers, "Server is back online");
    }
}

  email -> Server is back online
  sms   -> Server is back online

// TEMPLATE METHOD pattern: the abstract class fixes the STEPS (the algorithm),
// subclasses fill in the steps that vary. The "shape" of the work is reused;
// only the details change.
abstract class ReportGenerator {

    // The template method is FINAL so subclasses can't change the order of steps.
    final void generate() {
        System.out.println(header());
        for (String row : rows()) {
            System.out.println("  " + row);
        }
        System.out.println(footer());
    }

    // Steps that vary — left abstract for subclasses to define.
    abstract String header();
    abstract String[] rows();

    // A step with a sensible default — subclasses MAY override it.
    String footer() { return "  -- end of report --"; }
}

class SalesReport extends ReportGenerator {
    String header() { return "SALES REPORT"; }
    String[] rows() { return new String[]{ "Mon: $120", "Tue: $90" }; }
}

public class Main {
    public static void main(String[] args) {
        new SalesReport().generate();  // runs the FIXED algorithm, varied details
    }
}

SALES REPORT
  Mon: $120
  Tue: $90
  -- end of report --