Demo: pluggable notification channels

Examples

Step 1: The interface

public interface Notifier {
    void send(String to, String message);
}

One method, one purpose. This is the small, focused contract from lesson 1, not a "god" interface.

Step 2: Three implementations

public class ConsoleNotifier implements Notifier {
    @Override
    public void send(String to, String message) {
        System.out.println("[console] " + to + ": " + message);
    }
}

public class EmailNotifier implements Notifier {
    @Override
    public void send(String to, String message) {
        System.out.println("[email] To: " + to + " | Subject: Statement | Body: " + message);
    }
}

public class SmsNotifier implements Notifier {
    @Override
    public void send(String to, String message) {
        System.out.println("[sms] " + to + " <- " + message);
    }
}

Printing stands in for a real email or SMS service. A real implementation would call that service inside send, and nothing else in the program would need to change. Note public on each method, required because interface methods are public.

Step 3: The bank depends on the contract

public class Bank {
    private final Notifier notifier;

    public Bank(Notifier notifier) {
        this.notifier = notifier;
    }

    public void sendStatement(String customer, String contact, double balance) {
        notifier.send(contact, "Dear " + customer + ", your balance is " + balance);
    }
}

Bank has no new and no channel name. It is given a notifier and uses it. The type of the field, the constructor parameter, and the call are all Notifier.

Step 4: Run the same statement through all channels

public class Main {
    public static void main(String[] args) {
        Notifier[] channels = {
            new ConsoleNotifier(), new EmailNotifier(), new SmsNotifier()
        };
        for (Notifier channel : channels) {
            Bank bank = new Bank(channel);
            bank.sendStatement("Ana", "ana@example.com", 150.0);
        }
    }
}

Compile all .java files and run Main. The output (JDK 21):

[console] ana@example.com: Dear Ana, your balance is 150.0
[email] To: ana@example.com | Subject: Statement | Body: Dear Ana, your balance is 150.0
[sms] ana@example.com <- Dear Ana, your balance is 150.0

The same bank code produced three different behaviors. Look at the third line: a real SMS needs a phone number, not an email address. Here the to value is just a String that every channel interprets for itself, which is a simplification of the demo. A richer design could pass a customer object instead; that is for a later module.

Main is the one place that names the concrete classes. That matches the rule from the last lesson: choose the implementation in one place.

Step 5: The planted mistake

Now imagine a tired developer in a hurry. Email is the only channel today, so they write:

public class Bank {
    private final EmailNotifier notifier;       // the mistake: a class, not the interface
    public Bank(EmailNotifier notifier) { this.notifier = notifier; }
    ...
}

Everything still compiles in Bank. The failure shows up when Main tries to give the bank any channel:

Main.java:5: error: incompatible types: Notifier cannot be converted to EmailNotifier
            Bank bank = new Bank(channel);
                                 ^
1 error

If you change Main to pass new SmsNotifier() directly, the message names SmsNotifier instead. Either way, the lesson is the same: the bank has been welded to email, and supporting SMS now means editing Bank. That is the cost of depending on a class.

Notice what the mistake did not break: the code compiled in Bank itself. Only the caller noticed. In a large program, those callers may live in other files, other teams, or tests, and the failure appears far from the cause.

Step 6: Restore and verify

Change the field and constructor back to Notifier. Compile and run: the three lines return.

Then check the lab's rule: the bank class depends only on the interface. Open Bank.java and look for the words ConsoleNotifier, EmailNotifier, SmsNotifier. You can use your editor's search or a text-search command in your terminal (the command differs by operating system). They must not appear anywhere in the file, and there must be no new of any notifier. In the correct version, the only mention of Notifier is the interface type in the field, the constructor, and the call.

What you gained

Where it stops

The demo hides things a real system has: failures (what if sending fails?), different address formats, and retries. Each would be a design question of its own. The interface is only the first step.