Design Patterns in the JDK

A Singleton ensures a class has exactly one instance and gives global access to it. In Java you hide the constructor (make it private) and expose one shared instance, either created eagerly in a static field or lazily in a getInstance() method.

If two threads create a lazy singleton at the same time you can get two instances. Double-checked locking checks the field, locks only if it is null, then checks again. Without the volatile keyword on the field, another thread can see a half-built object, so you must mark the field volatile.

Even with a private constructor, reflection can call it, deserialization can build a second object, and clone() can copy it. Defend by throwing from the constructor if an instance exists, adding readResolve() to return the existing instance, and refusing to clone. Or just use an enum singleton, which blocks all of these.

Use a true Singleton only when there genuinely must be one instance, like a registry or a hardware accessor. For most shared services, create one instance and pass it where needed (dependency injection) instead, because hard-coded singletons are global state and hard to test.

Factory Method means asking a method to make an object instead of using new yourself. The method decides which concrete class to build and returns it, usually typed as an interface or parent class, so the caller doesn't depend on the exact type.

Both are static getInstance() factories. They don't return a fixed class — they look at your locale/region and pick the right concrete subclass (e.g. a Gregorian calendar, or a locale-specific number format) and hand it back typed as the abstract base. You get a ready, region-appropriate object without naming the concrete class.

An interface says what an object does; classes implement it. A factory method returns the interface, so the caller only knows the interface. The factory can pick or add new implementing classes later without changing callers. That's deferred instantiation: the 'which class' decision is postponed and isolated inside the factory.

A static factory is just a named static method that returns an object (like List.of). The GoF Factory Method is a pattern: a creator class has an overridable method that subclasses override to choose which product to build. Static factory = convenience; GoF = a hierarchy where subclasses decide the product.

Factories hide the concrete type, which is great for decoupling but costs discoverability and adds indirection. A static factory method can't be subclassed if the class has no public/protected constructor, factories aren't as obvious as new, and a creator hierarchy can explode into many subclasses. Use them where variation is real, not everywhere.

Factory Method is one method that creates one product (e.g. Calendar.getInstance()). Abstract Factory is an object with several creation methods that build a whole family of related products together (e.g. DocumentBuilderFactory).

Abstract Factory is a creational pattern: an object whose job is to create a family of related objects without you naming their concrete classes. DocumentBuilderFactory.newInstance() gives you a factory that builds matching XML parser objects.

Define abstract product interfaces, an abstract factory interface with a create method per product, and concrete factories that return one matching set of products. The client holds the abstract factory and calls its methods, never using new on concretes.

newInstance() searches an ordered list — a system property, a jaxp.properties file, the service-loader (META-INF/services), then the built-in default — and uses the first provider it finds. This lets you swap XML libraries without changing code.

Use Abstract Factory when you need several related objects that must come from the same consistent variant and that variant must be swappable. If you only need one object, or a DI container already wires implementations, a simpler factory or plain constructor is usually better.

Builder is a way to construct an object step by step using chained method calls, then a final build() call. It avoids constructors with lots of confusing parameters, and the result is usually an immutable object.

The builder collects values in its own mutable fields, then build() passes them to the target's private constructor, which stores them in final fields. After build() returns, the object can't be changed.

StringBuilder, Stream.Builder, and Locale.Builder are JDK examples. Each lets you add values with chained calls and then produces a final object — toString() for StringBuilder, build() for the other two.

You make the base builder generic in its own subtype: abstract class Builder<T extends Builder<T>>, have each fluent method return that type T via an abstract self() method overridden by subclasses to return this. This lets a subclass keep chaining the parent's methods without losing its own type.

Use a Builder when a class has many parameters, especially optional ones, and you want readable construction and an immutable result. For just a few parameters, a constructor, static factory, or a record is simpler and a Builder is needless boilerplate.

A shallow copy duplicates the object's fields but shares the objects those fields point to. A deep copy also duplicates the referenced objects so the copy is fully independent. Object.clone() gives a shallow copy; you must add deep copying yourself.

Prototype creates new objects by copying an existing instance instead of building one from scratch. In Java you implement Cloneable and override clone() to return a copy of the object.

Cloneable is a marker interface that doesn't contain clone(); clone() lives on Object, is protected, and copies shallowly while bypassing constructors. This makes correct cloning fragile, so Effective Java recommends copy constructors or copy factories instead.

Java's array clone() and types like ArrayList.clone() show the Prototype idea of copying. To choose, prefer copy constructors/factories for normal objects, use array clone() for arrays, and reach for true Prototype when you must copy objects whose concrete type you don't know at compile time.

Adapter is a wrapper that lets two incompatible interfaces work together. It takes an object with one interface and exposes it as another. In the JDK, InputStreamReader adapts a byte InputStream into a char Reader.

Arrays.asList wraps an array in the List interface without copying it. The list is a fixed-size view backed by the array: changing the list changes the array and vice versa, set works, but add and remove throw UnsupportedOperationException.

An object adapter holds the adaptee as a field and delegates to it (composition). A class adapter extends the adaptee and implements the target (inheritance). Java favors the object adapter because Java allows only single class inheritance.

All four wrap an object, but for different reasons. Adapter changes the interface; Decorator keeps the interface and adds behavior; Proxy keeps the interface and controls access; Facade hides a subsystem behind a simpler interface. InputStreamReader is an Adapter (bytes to chars); BufferedReader is a Decorator (still a Reader, adds buffering).

Use an Adapter when you can't or shouldn't change either side — third-party libraries, legacy code, or stable public APIs — to keep your code depending on your own clean interface instead of the foreign one. The cost is an extra layer to maintain and translate.

Decorator wraps an object to add behavior without changing its class. It implements the same type as what it wraps and forwards calls to it, adding extra work. The classic JDK example is java.io: BufferedInputStream wraps an InputStream to add buffering.

Each wrapper feeds bytes through the one it wraps, so order decides what happens in what sequence. Put buffering closest to the raw source. If you wrap in the wrong order, you can lose the buffer's benefit (slow) or transform bytes at the wrong stage.

Implement the same interface as the thing you wrap, store a reference to it, and forward each method to that reference, adding your extra behavior in the methods you care about. For example, a List wrapper that counts how many times add() is called before delegating to the real list.

All three wrap an object, but with different intent. Decorator adds behavior and keeps the same interface (BufferedInputStream over InputStream). Adapter changes the interface to a different one (Arrays.asList: array to List). Proxy controls access without changing behavior (java.lang.reflect.Proxy, lazy/remote/security gates).

Decorator gives flexible, runtime-composable features without a class explosion, following open/closed. The cost: many small objects, deep stacks that are hard to read and debug, easy-to-misorder wrapping, and lost object identity. The java.io API is often criticized for confusing, verbose wrapping with too many similar classes.

A proxy is a stand-in object that has the same interface as a real object. Calls go to the proxy first, which can add behavior (security checks, logging, lazy loading) and then forward to the real object.

Proxy.newProxyInstance generates a class at runtime that implements your interfaces. Every method call on it is routed to one InvocationHandler.invoke(proxy, method, args) method, where you add logic and usually call method.invoke(target, args) to delegate.

Both wrap an object of the same interface and forward calls. The difference is intent: a Decorator adds new behavior and is meant to be stacked, while a Proxy controls access (lazy creation, permissions, remoting) and is meant to be invisible to the caller.

Frameworks like Spring wrap your beans in proxies so they can run extra code (transactions, security, caching, logging) around your methods without you writing it. The cost: proxies only intercept calls that come through them, add reflection overhead, and make stack traces noisier.

A Facade is one simple class or method that hides a messy group of lower-level classes behind an easy entry point. In the JDK, java.nio.file.Files and the newer HttpClient are facades over more granular machinery.

Facade simplifies a complex subsystem behind one easy interface. Adapter changes one class's interface into a different one the caller expects. Proxy stands in for an object to control access (lazy, remote, security). All three wrap something, but for different reasons.

Facades like Files.readAllLines or HttpClient.send make the common case a one-liner and handle resource cleanup for you. But they load everything eagerly or assume defaults. For huge files, custom buffering, memory-mapping, or fine HTTP control, you drop to FileChannel/SocketChannel and configure it yourself.

Make the facade cover the common case with a tiny, intention-revealing API, but keep the underlying subsystem usable for advanced needs. Don't let the facade become a giant 'god object' that everyone depends on and that keeps growing.

Composite lets you treat a single object and a group of objects the same way. In Swing, both a single widget (like a JButton) and a container of widgets (like a JPanel) are Components, so code can handle either through the same Component type.

Because a Container 'is-a' Component, you can put a container anywhere a component is expected — including inside another container. That is what lets panels nest inside panels and makes the UI a deep tree instead of one flat list.

When you paint or lay out a container, it does its own work and then asks each child to do the same; if a child is itself a container, it repeats the process. This recursion walks the whole tree, and it works because every node is a Component, so the same call applies to leaves and groups alike.

Transparency means leaves and composites share the exact same interface (including add/remove), so clients never branch — but leaves get child methods that do nothing or fail. Safety means add/remove live only on the composite, so you can't misuse them, but clients must know they hold a composite. AWT puts add/remove on Container (safety) while keeping paint/visibility on Component (transparency).

Use Composite when your data is a genuine part-whole tree and clients should treat one item and a group of items the same way (UIs, file systems, document models). Avoid it when the structure isn't really a tree, when leaves and composites differ too much to share an interface honestly, or when forcing uniformity bloats the base type with methods most nodes don't need.

Adapter makes an existing class with the 'wrong' interface fit something you already have — it's added after the fact to bridge a mismatch. Bridge is planned from the start to keep an abstraction and its implementation separate so both can grow independently.

If something changes along two directions and you make a subclass for every combination, the number of classes multiplies (M×N). Bridge puts each direction in its own group and links them with a reference, so you only need M+N classes.

Bridge splits one thing into two parts that can change separately: an abstraction (the 'what') and an implementation (the 'how'). The abstraction holds a reference to the implementation, so you can mix and match them instead of writing a class for every combination.

There are four roles: the abstraction (the high-level interface clients use), refined abstractions (its concrete subclasses), the implementor (the low-level interface), and concrete implementors. The abstraction stores an implementor reference, usually passed in through its constructor, and calls it to do the real work.

Use Bridge when a type varies along two independent dimensions you expect to keep growing, so you split them to avoid a subclass explosion. Don't use it for a single varying dimension, a quick fix to a mismatched API (Adapter), or just swapping one algorithm (Strategy).

Small boxed Integers (-128 to 127) come from a shared cache, so == compares the same object and returns true. Larger values are separate objects, so == returns false even when the numbers are equal. Always use equals().

Flyweight reuses shared, unchangeable objects instead of creating new ones. The JDK does this for small Integer values: Integer.valueOf for numbers -128 to 127 returns the same cached object every time.

Autoboxing can silently create many objects (slow loops), throw NullPointerException when unboxing a null wrapper, and cause confusing == results. Use primitives in hot loops and equals() or Objects.equals() for comparison.

Integer holds a static IntegerCache: an array of pre-built Integer objects for -128 up to a high bound (default 127). valueOf indexes into it. The low bound -128 is fixed; only the high bound is configurable via a JVM flag.

Build your own cache when you create many identical, immutable objects and allocation/memory is a real cost — for example interning common values. Make the objects immutable, document that == is unreliable, and avoid leaking mutable or unbounded caches.

The old Observable/Observer classes were deprecated in Java 9 because they were weak and limited: Observable is a class (so you must extend it), it isn't thread-safe in a useful way, and it passes plain Object events. Use listeners, PropertyChangeSupport, or the reactive Flow API instead.

A bean keeps a PropertyChangeSupport helper object. Listeners register with addPropertyChangeListener. When a property changes, the bean calls firePropertyChange(name, oldValue, newValue), and every listener's propertyChange method runs with a PropertyChangeEvent. It only fires when old and new values actually differ.

Flow (added in Java 9) is the JDK's reactive-streams API: a Publisher produces items, a Subscriber consumes them. When you subscribe, you get a Subscription and must call request(n) to ask for n items — the publisher only sends up to what you requested. That request mechanism is backpressure, so a fast producer can't overwhelm a slow consumer.

A Swing component (the subject) keeps a list of listeners. You register one with e.g. button.addActionListener(...). When the user acts, the component fires an event and calls each listener's callback. All this runs on the Event Dispatch Thread (EDT), so listener code must stay on that thread and not block it.

Use synchronous listeners (PropertyChangeListener, Swing) for simple in-process events where the producer can safely call observers directly. Use the Flow reactive API for asynchronous streams of many items where a slow consumer needs backpressure. Never base new code on the deprecated java.util.Observable.

A Comparator is a small object that says how to order two items. You pass different Comparators to Collections.sort or List.sort to get different orderings without changing the sort code. That swappable rule is the Strategy pattern.

A functional interface has just one method, so instead of writing a whole class to hold a strategy, you can write it inline as a short lambda. Comparator is functional, so 'sort by age' becomes one line instead of a new class.

Chain Comparators: start with Comparator.comparing(key1), add .thenComparing(key2) for tie-breaks, and use .reversed() to flip a direction. Be careful where .reversed() applies and handle nulls explicitly so sorting doesn't throw.

Use a Strategy (pass behavior in, like a Comparator) when callers need to vary one step at runtime and combine behaviors freely. Use inheritance/Template Method when the variation is a fixed family known at design time. Strategy favors composition over subclassing.

Template Method is a pattern where a parent class writes the fixed steps of an algorithm in one method and leaves a few specific steps for subclasses to fill in. In Java you use an abstract class: a final/concrete method holds the skeleton and calls abstract methods the subclass must implement.

AbstractList already writes most of the List methods (iterator, indexOf, equals, etc.) using two abstract steps you provide: get(index) and size(). To make a read-only list you extend AbstractList and implement just those two methods.

A primitive is an abstract step the subclass must implement. A hook is a step with a default body in the base class, so overriding it is optional. The template method calls both; hooks let subclasses tweak behavior without being forced to.

Template Method varies steps using inheritance: a subclass overrides abstract methods, fixed at compile time. Strategy varies behavior using composition: you pass in an object (or lambda) that can change at run time. Prefer Strategy when you need flexibility or want to avoid deep class hierarchies.

Template Method ties subclasses tightly to the base class, so base changes can break them. A key Java trap: if a constructor (or initializer) calls an overridable method, the subclass's override runs before the subclass's own fields are initialized, leading to bugs. The skeleton's protected methods become a contract you must document and keep stable.

Iterable means 'can be looped over' — it has one method, iterator(), that hands you an Iterator. The Iterator does the actual walking with hasNext() and next(). The for-each loop uses both behind the scenes.

Most java.util collections return 'fail-fast' iterators. They count structural changes (modCount). If the collection is changed during iteration by anything other than the iterator's own remove(), the next next()/hasNext() throws ConcurrentModificationException.

The compiler rewrites for-each into a while loop that calls iterator() once, then loops on hasNext()/next(). Because you have no visible iterator handle, you cannot safely remove elements with the collection's remove() inside it.

ListIterator is a more powerful cursor for lists. On top of hasNext()/next(), it can go backwards (hasPrevious()/previous()), report indices, replace the current element with set(), and insert with add(). You get it from a List via listIterator().

Implement Iterable<T> and return an Iterator<T> from iterator(). The iterator's hasNext() must report whether more elements remain, and next() must return the next one (or throw NoSuchElementException when none). Then for-each just works.

The Command pattern wraps a request as an object so you can pass it around, store it, and run it later. In Java, Runnable and Callable are command objects: each bundles a piece of work in one method (run or call) that something else executes when it chooses.

execute(Runnable) just runs the task and returns nothing. submit(...) accepts a Runnable or Callable and returns a Future you can use to wait for completion, get a Callable's result, or cancel the task. submit also captures exceptions inside the Future instead of letting them escape.

Because tasks are objects, an executor can hold them in a queue and run them when a thread is free (deferred/queued). For time-based running, ScheduledExecutorService lets you schedule a task to run after a delay or repeatedly at a fixed rate or fixed delay.

If all threads are busy and the work queue is full, the executor can't accept the task, so it applies a rejection policy. The default policy throws RejectedExecutionException. You can choose other policies, like running the task on the caller's thread or silently discarding it.

Runnable and Callable are command objects and executors are the invoker, so they cover the core Command pattern: requests become objects you can queue, defer, and run elsewhere. But the textbook pattern often adds undo/redo and explicit receivers; Runnable has only one execute-style method, so undo and history aren't built in — you'd add them yourself.

The State pattern lets an object behave differently depending on what 'mode' it is in. Each mode is its own object with its own version of the methods, and the main object hands work to whichever mode it currently holds.

A JDBC Connection is either open or closed. While open you can run queries; once you call close(), the same methods become illegal and throw SQLException. So the connection's behavior depends on its open/closed state.

They look the same — both delegate to a swappable object behind an interface. The difference is intent: Strategy is an algorithm the client picks and usually keeps fixed; State is a mode the object switches between itself as conditions change, with the states often driving the transitions.

Java enums can give each constant its own method body, making a compact, type-safe state machine with no extra files — great for a fixed set of simple states. Separate classes or a sealed interface scale better when states hold their own data or have rich behavior.

Make illegal moves impossible or loud: each state only implements the operations valid in it, and invalid operations throw a clear exception (like IllegalStateException) instead of silently doing the wrong thing. Keep states immutable and validate transitions in one place.

It is a design pattern where a request passes through a series of handlers, and each one decides whether to process it or pass it along. Servlet Filters are a chain: each filter can act on a request, then call the next one.

In web.xml, filter order follows the order of the <filter-mapping> elements. With annotations or Spring, you set order explicitly (e.g. @Order or a FilterRegistrationBean). Order matters because earlier filters can short-circuit or change the request before later ones see it.

Implement Filter.doFilter: record the start time, call chain.doFilter to run the rest of the chain, then in a finally block compute elapsed time and log the method, URI, and duration. The code before the call is pre-processing; the code after is post-processing.

A filter short-circuits by not calling chain.doFilter and instead producing the response itself — for example writing a 401 or sending a redirect. Then no later filter or the servlet runs. You must fully complete the response and not commit it twice.

Both let you run code around a request in a chain. Filters live in the servlet container and see every request (even static files), working with raw request/response. Spring HandlerInterceptors live inside Spring MVC and know which controller/handler will run. Use filters for low-level/global concerns, interceptors for MVC-aware logic.

Visitor lets you add new operations to a group of related classes without changing those classes. You put each operation in a separate 'visitor' object, and each element class has an accept method that calls the right visit method on the visitor.

Java picks which method runs based on only one object's runtime type (the receiver). Visitor needs to choose based on two: the element type and the visitor type. The accept method does this in two steps — first dispatch on the element, then on the visitor — giving 'double dispatch'.

Visitor makes adding new operations easy (write one new visitor, touch no element classes) but makes adding new element types hard (you must add a visit method to every existing visitor). Plain polymorphism is the reverse.

A sealed interface lists all its permitted subtypes, so a pattern-matching switch over them can be checked by the compiler for completeness. You write each operation as a switch instead of a visitor, with no accept methods — cleaner for adding operations, while the compiler still flags you when a new element type is added.

The NIO file API uses it: Files.walkFileTree takes a FileVisitor. As the JDK walks a directory tree, it calls your visitor's methods (visitFile, preVisitDirectory, etc.) for each entry, so you supply the operation and the JDK supplies the traversal.

Mediator is a behavioral pattern where objects don't talk to each other directly. Instead, they talk through a central object called the mediator. This reduces tangled connections, so each object only knows the mediator, not all the others.

A dialog acts as the mediator and holds its buttons, text fields, and checkboxes. Each component, on change, just tells the dialog. The dialog contains the rules (like enabling a button) and updates the other components. Components never reference each other.

Because the mediator collects all the interaction rules in one class, it keeps growing as you add features. Eventually it knows and controls everything — a god object. Prevent it by keeping each mediator small and focused, splitting big ones into smaller mediators.

Mediator centralizes two-way coordination between peers that all know the mediator. Observer is one-way broadcast: a subject notifies subscribers that don't know each other. Facade is a simple front door to a subsystem; the subsystem doesn't know the facade. Pick by direction and who knows whom.

Avoid a Mediator when objects barely interact — the extra indirection just adds a class and hides simple calls. Also avoid one giant mediator for a whole system. Alternatives: keep direct calls when simple, or use an event bus for loose, many-to-many communication.

Memento lets you save an object's state to a separate object and restore it later (e.g. undo), without exposing the object's internals. The three roles are Originator (owns the state), Memento (the saved snapshot), and Caretaker (holds mementos but never reads them).

Make the Memento a private (or private static) nested class of the Originator and expose it to the outside only through a public marker interface. The Originator can read the nested class's private fields; the Caretaker holds it as the marker type and can't see anything.

A field-snapshot copies chosen fields by hand: fast, small, but you must write and maintain the copy code. A serialization-based memento serializes the whole object to bytes: automatic deep copy and no per-field code, but slower, larger, and needs Serializable.

Memento undoes by restoring a saved full state; Command undoes by storing each operation and applying its inverse. Use Memento when full snapshots are cheap and inverses are hard to compute; use Command when state is large but each change is small. They combine: a Command can store a Memento to undo itself.

Each memento is a full copy of state, so an unbounded history grows memory linearly. Fix it by bounding history depth, storing deltas instead of full snapshots, sharing immutable sub-state structurally, or moving older snapshots off-heap/to disk — choosing based on how big state is and how it changes.