What Are Design Patterns?

A design pattern is a named, reusable solution to a recurring design problem. It is not a piece of code you copy but a structure, a set of collaborating roles and the reasoning about when the structure helps. The classic catalogue groups them into creational, structural and behavioural families.

public class Main {
    public static void main(String[] args) {
        String text = "Hello World";
        System.out.println(new UpperCase().apply(text));
        System.out.println(new Reverse().apply(text));
    }
}

interface TextFormatter {
    String apply(String text);
}

class UpperCase implements TextFormatter {
    public String apply(String text) { return text.toUpperCase(); }
}

class Reverse implements TextFormatter {
    public String apply(String text) { return new StringBuilder(text).reverse().toString(); }
}

The strategy pattern is the simplest one to recognise. Instead of a method that branches on a flag or a type, the varying behaviour is extracted behind a small contract, and the caller is handed one implementation. The output shows the same text formatted two different ways, and the caller never asks which way it wants.

What that buys is extension without modification. A third formatting style is a third class, and nothing that already works is edited. It also makes the variations visible in the code as named types rather than as a chain of conditions.

The honest cost is indirection. A reader now has to find the implementation to know what happens, and every strategy is another class in the codebase. For one conditional with two branches, the pattern is probably overkill. It starts paying when there are several variations, when the order of the branches keeps growing, or when different callers need different variations at the same time.

They exist because certain design problems keep recurring, and because the solutions have been written down after being tested in many systems. A pattern gives you a starting structure and, more valuably, a shared vocabulary. When a colleague says the strategy pattern, both of you know the shape of the code before you discuss the details.

The thing patterns give you that a blog post does not is the trade-off. Every pattern has a cost that is written down next to the benefit. The observer pattern buys loose coupling between a subject and its listeners, and pays for it with the difficulty of tracing what happens when a notification fires. The singleton pattern guarantees one instance and pays with testability and global state.

Patterns also give you a decision framework. When a feature request arrives, the catalogue provides a menu of known approaches with known consequences, instead of an invented solution that nobody has seen before. That makes the design easier to review and easier to hand over.

The counterpoint is the pattern abuse that comes with learning them. Applying a pattern because it is on the list adds indirection to a problem that did not need it, and a codebase full of named patterns can be harder to read than one with straightforward code. The discipline is to name a pattern only when the problem matches its forces, and to be able to explain why.

When the problem is smaller than the pattern. A pattern is a structure with several roles, and each role is a file and a concept the reader has to hold. If the requirement is a single conditional with two branches, applying the strategy pattern buys a class hierarchy and an indirection in exchange for nothing that will ever be extended.

The second wrong case is when you cannot name the forces the pattern addresses. A pattern applied without a reason becomes ceremony. If you cannot say which of the problems the pattern solves you actually have, you are probably adding indirection for its own sake.

The third is when the pattern contradicts the architecture. A strategy pattern that has to be selected by a switch on a type is a switch with extra steps, and the switch will grow. A singleton in a system that runs many tenants is not a singleton at all, it is a global variable with extra steps and a worse failure mode.

The fourth is the cost of the pattern's own complexity. The observer pattern, the proxy pattern and the decorator pattern all add indirection that a debugger cannot follow easily, and in a system where debugging is the normal activity that cost is real.

The rule to state in an interview is that patterns are solutions to recurring problems with known trade-offs, so they earn their place when you recognise the problem and can name the trade-off you are accepting. If you cannot name either, plain straightforward code is the better answer, and saying so is a sign of judgement rather than ignorance.