Programming to an Interface, Not to an Implementation: 25-Comp-B11 Advanced Software Design, December 2018, Q22

Question 22: Programming to an Interface, Not to an Implementation (Part V)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

The principle says that client code should declare its variables, parameters, and return types using an ABSTRACT type (an interface or abstract base class) that describes only the operations it needs, never a specific CONCRETE class — so the client depends on WHAT an object can do, not on WHICH exact class provides it.

Violating the principle (Java):

ArrayList<String> names = new ArrayList<>();
void printAll(ArrayList<String> list) { ... }

Here printAll's parameter type is the CONCRETE class ArrayList. Any caller holding a different List implementation (a LinkedList, for instance) cannot call printAll at all without first copying its data into a new ArrayList, and if the concrete implementation is later swapped project-wide (e.g., for a LinkedList better suited to frequent insertions), every method signature naming ArrayList must change.

Following the principle (Java):

List<String> names = new ArrayList<>();
void printAll(List<String> list) { ... }

Now printAll depends only on the List interface's operations (get, size, iteration). The concrete instance assigned to names can be swapped — new LinkedList<>() instead of new ArrayList<>() — with zero change to printAll or to any other code that only ever names the List interface.

C++ equivalent uses a pointer/reference to an abstract base class with pure virtual functions: a function taking Shape& s (an abstract base with a pure virtual draw()) works unmodified whether the actual object passed is a Circle or a Square, whereas a function taking a concrete Circle& can never accept a Square at all.

Why it matters. This is the exact mechanism that makes Question 17's Template Method extensible (client code calls validate() on a CardValidator-typed reference, never on a named concrete subclass) and is the concrete implementation technique underlying the open–closed principle: new implementations of the interface can be added without touching client code that depends only on the interface itself.

Concept & Theory: Depend on Capability, Not on Concrete Identity

Topic: Declaring types as the most abstract interface that satisfies the client's actual needs.

Key relations: Client declares interface type → any conforming concrete implementation is substitutable (Question 11's LSP is the formal guarantee that this substitution is safe) → new implementations require zero client changes.

Why this works: A client that only ever calls interface operations cannot, by construction, depend on any detail specific to one implementation, since it has no way to even reference such a detail.

Common pitfall: Declaring a field or parameter as the concrete class "because that's what I'm using right now" — this is nearly free to avoid (declare the interface type instead) and pays off the first time a second implementation is needed.

Source: Gamma, Helm, Johnson & Vlissides, Design Patterns, Introduction ("Program to an interface, not an implementation").

Question 22 of 28: Programming to an Interface, Not to an Implementation

Question 22: Programming to an Interface, Not to an Implementation (Part V)