Java Design Patterns Explained: Part 1 — Understanding Design Patterns with Real-World Social Media Examples

Design Patterns

Every developer eventually reaches a point where writing code isn’t the biggest challenge — designing clean, maintainable, and scalable software is.

Imagine you are building an application like Instagram or WhatsApp. Millions of users are posting photos, sending messages, receiving notifications, and following other users simultaneously.

Would you write everything from scratch every time?

Definitely not….!💭

Software engineers have already solved many common software design problems over the years. These proven solutions are called Design Patterns.

A design pattern is not a library, framework, or piece of code that you copy and paste. Instead, it is a reusable blueprint for solving a recurring design problem.

Think of it as a recipe. Different chefs may cook the same dish differently, but they all follow the same basic recipe. Similarly, developers may implement a design pattern differently, but the underlying idea remains the same.

Why Do We Need Design Patterns?

Suppose your team is developing a social media application.

One developer writes code one way…

Another developer solves the same problem differently…

A third developer invents an entirely new approach…

After a few months, the project becomes difficult to maintain because everyone follows different coding styles and different architectures.

Here comes the Design Patterns (OG)🐦‍🔥. Design patterns provide a common language.

Instead of explaining hundreds of lines of code, a senior developer can simply say:

“Let’s use the Factory Pattern here.”

Immediately, every experienced developer understands the expected solution.

This makes large projects easier to understand, maintain, and extend.

Classification of Design Patterns:

The famous Gang of Four (GoF) categorized design patterns into three major groups.

Creational Design Patterns:

Creational patterns focus on how objects are created.

Instead of creating objects directly using the new keyword everywhere, these patterns provide smarter ways of creating objects.

The creational patterns are:

1. Singleton Pattern
2. Factory Pattern
3. Abstract Factory Pattern
4. Builder Pattern
5. Prototype Pattern

Let’s understand with example:

Imagine Instagram.

Whenever a new user signs up, Instagram creates a User object.

Whenever someone uploads a photo, Instagram creates a Post object.

Whenever someone comments, Instagram creates a Comment object.

Creating these objects efficiently and consistently is the responsibility of creational patterns.

Structural Design Patterns:

Structural patterns focus on how different objects are connected together.

Sometimes two classes cannot directly communicate because they have different interfaces.

Sometimes we want to add new features without modifying existing code.

Structural patterns solve these problems.

The structural patterns are:

1. Adapter Pattern
2. Bridge Pattern
3. Composite Pattern
4. Decorator Pattern
5. Facade Pattern
6. Flyweight Pattern
7. Proxy Pattern

Let’s understand with example:

Suppose Instagram wants to integrate with Spotify.

Instagram and Spotify have different APIs.

Instead of changing Instagram’s entire codebase, an Adapter Pattern helps both systems communicate.

Behavioral Design Patterns:

Behavioral patterns focus on how objects communicate with each other.

These patterns define responsibilities between objects.

The behavioral patterns are:

1. Chain of Responsibility Pattern
2. Command Pattern
3. Interpreter Pattern
4. Iterator Pattern
5. Mediator Pattern
6. Memento Pattern
7. Observer Pattern
8. State Pattern
9. Strategy Pattern
10. Template Method Pattern
11. Visitor Pattern

Let’s understand with example:

Suppose you follow your favorite YouTuber.

The moment they upload a video, millions of subscribers receive notifications.

This communication between one publisher and many subscribers is handled using the Observer Pattern.

Advantages of Design Patterns:

1. Easier to understand
2. Easier to maintain
3. Easier to test
4. Easier to extend
5. Less tightly coupled
6. More reusable
7. More scalable
8. Based on industry best practices

This is one of the reasons why frameworks like Spring Boot internally use several design patterns.

Let’s Deep Dive into the Singleton Design Pattern:

Singleton Design Pattern

Now let’s understand one of the most popular and most frequently asked interview questions — the Singleton Pattern.

What is the Singleton Pattern?

The Singleton Pattern ensures that only one object of a class exists throughout the entire application.

Instead of allowing developers to create unlimited objects, the class itself controls object creation.

Whenever someone asks for an object, the same object is returned every time.

Why Do We Need Singleton?

Let’s understand with example:

Imagine Instagram has a service responsible for sending push notifications.

Whenever someone likes your post…📪

Whenever someone comments…🗨️

Whenever someone follows you…🚶‍♂️‍➡️

Whenever someone sends a message…💬

Every feature needs to use the Notification Service.

Now imagine every feature creates its own NotificationService object.

NotificationService notification1 = new NotificationService();

NotificationService notification2 = new NotificationService();

NotificationService notification3 = new NotificationService();

NotificationService notification4 = new NotificationService();

If millions of users are active, thousands of unnecessary NotificationService objects are created.

This wastes memory.

It increases garbage collection.

It makes resource management difficult.

Instead, Instagram creates only one NotificationService object and shares it everywhere.

That is exactly what the Singleton Pattern does.

Let’s understand with another example:

Think about WhatsApp.

Suppose WhatsApp has a configuration object.

The configuration contains information like:

→ Maximum file upload size → API URL → Encryption settings → Server timeout → Application version

Should every chat screen create its own configuration object?

Of course not.🙅🙅‍♂️🙂‍↔️

Every screen should use the same configuration.

A Singleton is the perfect solution.

Let’s understand with simple example:

Imagine your college has only one Principal.

Every Student, Every Lecturer, Every Department communicates with the same Principal.

Nobody creates a new Principal whenever they have a problem.

The Principal is shared by everyone.

A Singleton object behaves exactly like that Principal.

How Does Singleton Work?

A Singleton class follows three important rules.

Rule 1

The constructor is private.

private NotificationService() {

}

This prevents other classes from creating objects using the new keyword.

Rule 2

The class stores its own object.

private static NotificationService instance;

Since the variable is static, it belongs to the class rather than individual objects.

Rule 3

A public method returns the same object every time.

public static NotificationService getInstance() {

    if(instance == null) {
        instance = new NotificationService();
    }

    return instance;
}

If the object does not exist, it creates one.

Otherwise, it simply returns the existing object.

Complete Java Example:

public class NotificationService {

    private static NotificationService instance;

    private NotificationService() {
        System.out.println("Notification Service Started");
    }

    public static NotificationService getInstance() {

        if(instance == null) {
            instance = new NotificationService();
        }

        return instance;
    }

    public void sendNotification(String message) {
        System.out.println(message);
    }

}

Using the Singleton:

public class Main {

    public static void main(String[] args) {

        NotificationService service1 =
                NotificationService.getInstance();

        NotificationService service2 =
                NotificationService.getInstance();

        System.out.println(service1 == service2);

        service1.sendNotification("New Like");

        service2.sendNotification("New Comment");
    }

}

Output:

Notification Service Started

true

New Like

New Comment

Notice something interesting.

Even though we requested the object twice…

The constructor executed only once.

Both variables point to the exact same object.

Where Is Singleton Used?

Singleton is useful whenever the application should have only one shared instance.

1. Application configuration
2. Logging service
3. Cache manager
4. Notification service
5. Database connection manager or connection pool manager
6. Feature flag manager
7. Metrics collector

Does Spring Boot Use Singleton?

OfCourse., In fact, this is one of the best real-world examples.

When you write:

@Service
public class UserService {

}

Spring creates only one object of UserService by default.

Whenever another class needs UserService, Spring injects the same object instead of creating a new one.

This is why Spring beans are Singleton scoped by default.

Advantages of Singleton:

1. Only one object is created, reducing memory usage.
2. Shared resources are managed consistently.
3. Global access to a common object becomes easy.
4. Configuration remains centralized.
5. Expensive object creation happens only once.
6. It improves performance for shared services.

Things to Be Careful About:

Singleton is powerful, but it should not be overused.

If every class becomes a Singleton, your application may become tightly coupled and harder to test.

Use Singleton only when there is a genuine requirement for exactly one shared instance across the application.

Conclusion:

The Singleton Pattern is one of the simplest yet most widely used design patterns in Java. Whether you’re building a small application or a platform like Instagram or WhatsApp, there are many services — such as notification management, configuration, logging, or caching — that naturally fit the Singleton approach.

Understanding why the Singleton Pattern exists is more important than memorizing its code. Once you recognize situations where only one shared object should exist, choosing this pattern becomes straightforward.

The Singleton Pattern is just the beginning of our Design Patterns journey. While it solves the problem of ensuring a single shared instance, many real-world applications require a flexible way to create different types of objects without tightly coupling the code. That’s exactly where the Factory Pattern comes in.

In the next article, we’ll explore the Factory Design Pattern using relatable social media examples, understand the problem it solves, implement it in Java, and see how frameworks like Spring Boot use it internally. Stay tuned!

I hope everyone understand this topic. If you have any queries please contact me. If you found this article helpful, I would be grateful if you could clap and follow me on Medium, Twitter, and LinkedIn. Your support enables me to continue creating content like this. Thank you, and happy coding! ✌️