Design Patterns in Java: Not Just a Resume Checkmark

Design Patterns in Java: Not Just a Resume Checkmark

Every Java developer has heard the phrase at least once: "Use design patterns." But often it sounds like a mantra. As if, if you don't use Singleton or Factory, you're a bad programmer. In reality, design patterns in Java are not a dogma or a mandatory element of every project. They are a tool. And like any tool, it needs to be applied appropriately.

In this article, we'll figure out why patterns are needed at all, when their use is justified, and when it's better to write simple code without frills. And of course, we'll look at live examples in Java.

What are Design Patterns and Why Are They Important

Design patterns are proven solutions to typical problems. You don't have to invent them from scratch. They were born from the experience of thousands of developers. When you encounter a problem that someone has already solved before you, a pattern provides a ready-made scheme.

But there is a nuance. Design patterns in Java do not exist in a vacuum. They are closely related to the SOLID principles. If you don't understand why an interface is needed or why you should extract logic into a separate class, patterns won't help you. They merely formalize these principles.

When to Apply Patterns and When Not To

The golden rule: a pattern is a solution, not a goal. You don't need to implement Abstract Factory just because "it's the done thing." Ask yourself:

\n
• Does this pattern solve my current problem?
\n
• Will it simplify code maintenance in the future?
\n
• Will it not complicate understanding for newcomers on the team?
\n

If the answer to all three is "yes" — use it confidently. If at least one is "no" — perhaps you should look for a simpler solution.

When patterns are really needed:

\n
• The code is growing and becoming difficult to maintain
\n
• Flexibility is required: adding new functionality without changing the old
\n
• Working in a team: patterns are a common language
\n

Basic Design Patterns in Java with Examples

Let's look at four of the most popular patterns from the Gang of Four. They cover 80% of typical tasks.

1. Singleton: When There Should Be Only One Object

Purpose: Ensures that a class has only one instance and provides a global point of access to it.

When to use: Loggers, configurations, database connection pools. But don't overuse it — Singleton is often criticized for hidden dependencies.

Example in Java:

public class DatabaseConnectionPool {\n    private static volatile DatabaseConnectionPool instance;\n    private final int maxConnections = 10;\n\n    private DatabaseConnectionPool() {\n        // private constructor\n    }\n\n    public static DatabaseConnectionPool getInstance() {\n        if (instance == null) {\n            synchronized (DatabaseConnectionPool.class) {\n                if (instance == null) {\n                    instance = new DatabaseConnectionPool();\n                }\n            }\n        }\n        return instance;\n    }\n\n    public Connection getConnection() {\n        // logic for obtaining a connection\n        return new Connection();\n    }\n}

Note the volatile and double-checked locking. This is a thread-safe Singleton. Without this, in a multi-threaded environment, you could get two different instances.

2. Factory Method: Delegating Object Creation

Purpose: Defines an interface for creating an object but lets subclasses alter the type of object that will be created.

When to use: When it is not known in advance which specific class will be needed. For example, creating different types of documents (PDF, Word, Excel).

Example in Java:

// Product interface\ninterface Document {\n    void open