البرمجة نحو واجهة

Written Explanation

The problem: depending on a class

class BadBank {
    private final EmailNotifier notifier;
    BadBank(EmailNotifier n) { this.notifier = n; }
    void sendStatement(String customer, double balance) {
        notifier.send(customer, "Balance: " + balance);
    }
}

BadBank works, but it is married to email. If the product needs SMS, the compiler stops you:

error: incompatible types: SmsNotifier cannot be converted to EmailNotifier

The only way to support SMS is to edit BadBank. Every new channel would mean another edit, in a class that has nothing to do with channels.

The fix: depend on the contract

class Bank {
    private final Notifier notifier;                  // the interface type
    Bank(Notifier notifier) { this.notifier = notifier; }
    void sendStatement(String customer, double balance) {
        notifier.send(customer, "Balance: " + balance);
    }
}

Three small changes made the difference: the field type is Notifier, the constructor parameter is Notifier, and the call is the same. Bank no longer mentions email, SMS, or console. It knows only the contract.

Passing the dependency in

Bank does not create its notifier with new. It receives one through the constructor. The caller decides:

Bank bank = new Bank(new EmailNotifier());

Handing a class what it needs, instead of letting it build its own, is often called dependency injection. You do not need a framework for it: a constructor parameter is enough. (Frameworks such as Spring automate the same idea later in the roadmap.)

One place to choose

Choose the concrete class in one spot, usually at the start of the program (main or a setup class). Everywhere else, use the interface type. Then a change from email to SMS is a one-line edit in that one spot, and the rest of the program is untouched.

Fakes for testing

Because Bank accepts any Notifier, a test can pass a tiny recording class:

class RecordingNotifier implements Notifier {
    final StringBuilder log = new StringBuilder();
    @Override public void send(String to, String message) {
        log.append(to).append('|').append(message).append(';');
    }
}

The test runs sendStatement and checks what was recorded. No real email is sent, and the test is fast and repeatable. This is a major reason to prefer the interface, and later testing modules build on it.

What to declare as what

The same habit in the standard library

You will meet the collections library later in the course, but you can read this line already: List<String> names = new ArrayList<>();. The variable type is the interface List, and ArrayList appears only after new. If the project later wants a different list implementation, only the right-hand side changes. (This is a preview: you do not need to know List yet.)

When not to use an interface

Do not invent an interface for everything. A class that is a plain value holder (an address, a money amount) or that will certainly never have a second implementation does not need one. The cases where the habit pays off are boundaries: things that talk to the outside world (messages, storage, other services) or that you want to replace in tests.

Where the analogy stops

A wall does not choose its own plug, but a program has to pick a concrete class somewhere. That "somewhere" cannot be avoided. The aim is only to keep it in one place.