Bridge
Rare. Named in books and almost never wanted in an interview. Read once so the word does not surprise you, then move on.
Start with the problem
corpus/lru-cache needs a rule for which key gets evicted when the cache is full. C4 names the instinct directly: "wanting the base's code is not the same as needing to be the base." Here that instinct is to make LruCache an abstract class with an abstract pickVictim() method, then write LfuCache extends LruCache overriding it for least-frequently-used.
Watch where it goes
A second, independent requirement arrives: a write-through backing store, wanted for both eviction rules. With eviction expressed through inheritance, supporting "LRU with write-through" and "LFU with write-through" leaves two options. One is copying the write-through logic into each subclass. The other is a second layer, LruWriteThroughCache extends LruCache and `LfuWriteThroughCache extends LfuCache`, each reimplementing the same storage behaviour. Two independent axes, which eviction rule and whether to write through, turn into a subclass for every combination. lessons/C4/idea.md prices this out on this exact corpus problem: two eviction rules and a write-through requirement cost two new classes under composition, against a multiplying cost under inheritance.
The move
Split the two axes into two separate hierarchies, connected by a held reference instead of extends.
interface EvictionPolicy {
void onInsert(String key);
void onAccess(String key);
void onRemove(String key);
String victim();
}
final class LruCache implements LruCacheApi {
private final EvictionPolicy policy;
LruCache(EvictionPolicy policy) {
this.policy = policy;
}
// put/get delegate eviction decisions to policy, never override it
}LruCache holds an EvictionPolicy instead of extending one. A new eviction rule is a new EvictionPolicy implementation. A new storage behaviour, the write-through requirement, is a new class that composes an EvictionPolicy the same way LruCache does, rather than a subclass of LruCache itself. N eviction rules plus M storage behaviours costs N plus M classes, not N times M.
An abstraction whose implementation detail is a separate hierarchy, connected by composition rather than inheritance, is what GoF calls Bridge.
What modern Java changes here
Nothing about the shape changes. What has changed is the vocabulary around it. Nobody in a current Java codebase says "add a Bridge here." They say "extract an interface," or cite composition over inheritance, which is the same move without the 1994 name attached. corpus/lru-cache's own EvictionPolicy interface is a working Bridge, and the lesson that teaches it, C4, never uses the word once.
When naming it is wrong
Saying "I'll use the Bridge pattern here" out loud in an interview spends time on a label while the interviewer is waiting to see the composition happen. Sketch the interface, hold it as a field, and move on. If asked what the move is called, say "composition instead of inheritance, so the eviction rule and the storage behaviour can vary independently." That answer states the reason. The pattern's name states only the label.
The pattern is unearned, the same as everywhere else in this app, when there is only one axis of variation in sight. C4's own test settles it directly: name a caller that would happily be handed a subclass in place of the base, and ask whether a second independent axis of variation actually exists. One eviction rule and no second axis in view means there is nothing here to bridge yet.
Where this lives in the app
The anchor given for this page is C4, and it is the strongest anchor in this batch, verified directly. corpus/lru-cache's EvictionPolicy, held as a field rather than extended, is this pattern exactly, and C4's own lesson measures the N-times-M cost of the inheritance alternative on this exact problem. Nothing in this app calls it Bridge. This page's honest job is to say that C4 already teaches the technique in full, under its own name. It exists only to attach the word a textbook would use for it.