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

Question 26: Programming to an Interface, Not 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 client code should declare variables, parameters, and return types using an ABSTRACT type (an interface or abstract base class) describing 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) { ... }

printAll's parameter type is the CONCRETE class ArrayList. A caller holding a different List implementation (e.g. a LinkedList) cannot call printAll without first copying its data, and if the concrete implementation is later swapped project-wide, every signature naming ArrayList must change.

Following the principle (Java).

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

printAll now depends only on the List interface's operations. The concrete instance assigned to names can be swapped (new LinkedList<>() instead) with zero change to printAll or 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. This is the same 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, and is the concrete mechanism that makes Question 22's composed objects, and Question 15's factories, swappable at all.

Concept & Theory: Depending on Capability, Not on a Concrete Provider

Topic: Naming an abstract type in client code, rather than a concrete class, is what makes later substitution possible at all.

Key relations: Client depends on interface → any conforming implementation is swappable with zero client change.

Why this works: A client that never names a concrete class cannot possibly be broken by a NEW concrete class being introduced, as long as it satisfies the same interface.

Common pitfall: Declaring a field's TYPE as the interface but still calling a concrete-class-only method on it via an explicit downcast, which silently reintroduces the same coupling the principle was meant to avoid.

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

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

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