Java’s I/O API has one of the most recognizable lines in all of Java: new BufferedReader(new InputStreamReader(socket.getInputStream())). That’s three objects stacked inside each other. Each one adds a single capability — buffering, character decoding, raw bytes — and the result is a clean reader your code can use with readLine(). You’ve been using the Decorator pattern since your first Java program. This article explains exactly how it works and how to apply it in your own code.
The Decorator pattern lets you attach new behaviour to an object by wrapping it in another object that implements the same interface. You can stack as many wrappers as you need, in any order, and the outside world sees only the outermost interface. No subclasses. No modification to the original class. No feature flags inside the component itself.
A file system has files and directories. A directory can contain files and other directories. When your UI asks “how big is this item?”, it shouldn’t need to check whether it’s talking to a file or a directory — it should just call getSize() and get a number back. The Composite pattern makes that possible by giving both leaves (files) and composites (directories) the same interface, so callers never need to distinguish between them.
This guide builds a file system tree from scratch, explains how the recursive structure works, and maps the pattern to real examples in the JDK. If you’ve ever wondered how Swing’s component hierarchy, XML DOM trees, or expression evaluators work under the hood, this is the pattern behind all of them.
Suppose you’re building a remote control library. You have basic remotes and advanced remotes. You have TVs, radios, and smart speakers. Without a plan, you end up writing: BasicTVRemote, BasicRadioRemote, BasicSpeakerRemote, AdvancedTVRemote, AdvancedRadioRemote, AdvancedSpeakerRemote. Six classes to cover 2 remotes × 3 devices. Add a Blu-ray player and you need two more. Add a “gaming remote” and you need three more. The class count grows as M × N — and every class mixes remote logic with device logic into a tangled lump.
The Bridge pattern breaks this M×N explosion into M+N. You define the remote control hierarchy independently, you define the device hierarchy independently, and you connect them with a single reference — the bridge. Adding a new device means one class. Adding a new remote means one class. Neither side knows the other’s internal details.
Your application has a clean PaymentGateway interface used everywhere. Now you need to integrate Stripe, whose SDK uses cents instead of dollars, different method names, and its own result objects — none of which match your interface. You can’t modify Stripe’s SDK, and you don’t want to scatter Stripe-specific code throughout your application. The Adapter pattern is the precise solution: write a thin wrapper that translates one interface into the other, and the rest of your code never knows Stripe exists.
This guide builds the pattern from first principles. We’ll look at why incompatible interfaces are inevitable in real projects, implement a full Object Adapter (the variant you’ll use 95% of the time), compare it to the Class Adapter form, and then map the pattern onto real JDK examples you already use every day.
Your application needs exactly one database connection pool. Or one configuration registry. Or one thread-managing scheduler. Creating two by accident would be a bug — yet nothing in Java’s language rules stops you from calling new ConnectionPool() a hundred times. The Singleton pattern solves this by making the class itself responsible for ensuring only one instance ever exists.
This guide builds every major Singleton implementation from the simplest to the most robust, explaining exactly what breaks in each naïve version so the next implementation makes sense. By the end you will know which variant to use by default, which to avoid, and how Singleton fits into modern Spring applications.
You have a complex Document object: 50 fields loaded from a database, nested objects, pre-computed formatting. A user requests a “duplicate” of it with one field changed. Rebuilding it from scratch through the database query path is expensive. Re-running a complex initialization sequence just to get a near-identical copy is wasteful. The Prototype pattern says: copy the existing object instead. Start with what you have, change what you need.
This guide builds the Prototype pattern from the problem it solves, explains the critical difference between shallow and deep copying, covers Java’s Cloneable pitfalls, and shows the preferred copy constructor alternative. By the end you will know how to copy objects safely and which approach to use in modern Java code.
You need to create a HttpRequest object. It has a URL, a method, headers, a body, a timeout, authentication credentials, proxy settings, and retry configuration. Most of these are optional. How do you construct it? A constructor with 8 parameters is unreadable — which argument is the timeout and which is the retry count? A setter-based approach leaves the object in an inconsistent half-configured state until the last setter is called. The Builder pattern gives you a third option: a fluent, readable, safe construction API.
This guide builds the Builder pattern from the problem it solves to a full implementation, covers Lombok’s @Builder shortcut, and explains the Director role that many tutorials skip.
