Program to Interfaces, Not Implementations

Two ways to declare the same thing

Suppose a function needs a list of orders. There are two ways to declare what it accepts. Watch only the type — the body is identical.

// Programming to an IMPLEMENTATION — locked to one class
function process(orders: Order[]) { ... }          // (TS arrays are concrete)

// In Java the difference is sharp:
void process(ArrayList<Order> orders) { ... }      // ⚠️ only an ArrayList fits
void process(List<Order> orders)      { ... }      // ✅ any List fits

The second version asks for a List — the contract. Anything that is a List satisfies it: ArrayList, LinkedList, an immutable list, a list someone hands you from a library. The first version asks for an ArrayList — one specific class. Now only an ArrayList is allowed in the door, and you are stuck with that decision everywhere this function is called.

What you actually buy: the swap is free

Say you start with ArrayList and later discover the code does tons of inserts at the front, where LinkedList is faster. If you programmed to the interface (List), you change one line — the place that builds the list — and every consumer keeps working untouched, because they only ever asked for a List:

List<Order> orders = new ArrayList<>();   // before
List<Order> orders = new LinkedList<>();  // after — the ONLY line that changed

// Every function that takes List<Order> keeps compiling and running.
// process(orders);  totalValue(orders);  report(orders);  // all untouched

If instead you had typed everything as ArrayList<Order>, that one change would ripple into every function signature, every field, every variable that named the concrete class. You'd be editing dozens of lines to swap one object. That is the price of hard-wiring.

The hidden trap: leaking the concrete class's extra methods

There's a subtler cost to naming the concrete type. A concrete class often has extra methods the interface doesn't promise. If you declare ArrayList, a caller might quietly start using ensureCapacity(...) — an ArrayList-only method. Now you can't swap to LinkedList even if you wanted to, because real code depends on a method the new class doesn't have. Declaring the interface keeps everyone honest: they can only call what the contract promises, so the swap stays possible.

The rule of thumb

• Declare the widest type that does the job. Need to iterate and add? Declare List, not ArrayList. Need only to iterate? Declare Iterable or Collection.
• Return the contract too. A method that returns ArrayList leaks its implementation to every caller; returning List keeps you free to change the internals later.
• Construct with the concrete class — in one place. The single line new ArrayList<>() is fine; that's where the choice belongs. Just don't let the concrete name spread into signatures and fields.

Type to the contract by default; introduce one where variation is real

Two separate habits live under this rule. The first is free and you should do it almost always: when a contract already exists (List, Collection, Reader, Comparator), declare your variables, parameters, and returns as that contract. The second — creating a new interface — is a design decision you make only where genuine variation exists.

• A standard library already has the contract — declare List/Map/Iterable instead of ArrayList/HashMap/Vector. Pure upside; do it everywhere.
• There really are multiple implementations — email vs. SMS senders, MySQL vs. in-memory repositories, real vs. fake clocks. Define an interface and type to it.
• You want a fake for tests — if you need to substitute a stub/mock, the seam is a contract. Declare the interface so the test double can stand in.
• A public API boundary — returning a contract keeps you free to change internals later without breaking callers.