Common design patterns: Java Programming (Core to Spring Boot) (Expert)

Why patterns?

Patterns give teams a shared vocabulary: saying "use a Strategy here" communicates a whole design in two words. They come from the 1994 "Gang of Four" book and decades of practice. Learn the problem each solves; do not force them into code that does not need them.

Singleton: exactly one instance

java

public enum AppConfig {          // the simplest thread-safe singleton
    INSTANCE;
    private final String region = "ap-south-1";
    public String region() { return region; }
}
AppConfig.INSTANCE.region();

In Spring apps you rarely write singletons yourself: beans are singletons by default.

Classic singletons with a static getInstance() need care with threads (double-checked locking with volatile, or the holder-class idiom). Singletons are global state, which makes testing harder; prefer dependency injection.

Factory: hide which class is created

java

interface Notifier { void send(String to, String msg); }
class SmsNotifier implements Notifier { public void send(String t, String m) { … } }
class EmailNotifier implements Notifier { public void send(String t, String m) { … } }

class NotifierFactory {
    static Notifier forChannel(String channel) {
        return switch (channel) {
            case "sms" -> new SmsNotifier();
            case "email" -> new EmailNotifier();
            default -> throw new IllegalArgumentException("Unknown channel: " + channel);
        };
    }
}

Builder: many optional fields

java

Order order = Order.builder()
        .customer("Asha")
        .item("Kurta", 1)
        .item("Dupatta", 2)
        .giftWrap(true)
        .deliveryNote("Call before arriving")
        .build();                     // validates and creates an immutable Order

Readable compared with new Order("Asha", items, true, null, null, "Call before arriving", false). Lombok's @Builder can generate this.

Strategy: swap an algorithm

java

interface FareStrategy { long fare(int km); }
class SleeperFare implements FareStrategy { public long fare(int km) { return 50 + km * 1; } }
class AcFare implements FareStrategy { public long fare(int km) { return 150 + km * 3L; } }

class Ticketing {
    private final FareStrategy strategy;
    Ticketing(FareStrategy strategy) { this.strategy = strategy; }
    long price(int km) { return strategy.fare(km); }
}
// With lambdas: FareStrategy tatkal = km -> 300 + km * 4L;

Observer: notify many listeners

java

interface OrderListener { void onPlaced(Order o); }
class OrderEvents {
    private final List<OrderListener> listeners = new ArrayList<>();
    void subscribe(OrderListener l) { listeners.add(l); }
    void placed(Order o) { listeners.forEach(l -> l.onPlaced(o)); }
}
events.subscribe(o -> sms.send(o.phone(), "Order placed"));
events.subscribe(o -> inventory.reserve(o));

Spring's ApplicationEventPublisher and @EventListener implement this pattern.

Pattern	Where you see it in Java/Spring
Singleton	Spring beans (default scope), Runtime.getRuntime()
Factory	List.of, Calendar.getInstance, BeanFactory
Builder	StringBuilder, HttpRequest.newBuilder(), Lombok @Builder
Strategy	Comparator passed to sort
Observer	Event listeners, Spring application events
Template method	JdbcTemplate, abstract classes (module 5)
Proxy	Spring @Transactional and AOP wrap your beans in proxies

Careful: Pattern overuse is real: an AbstractSingletonProxyFactoryBean for a 200-line app is a joke for a reason. Use a pattern when its problem appears (many optional constructor arguments → Builder; growing if/else on types → Strategy), not to show you know it.

Think of it like this: Design patterns are like standard dance steps: once two dancers both know the "waltz", they can perform together without discussing every move. In code, "Builder" or "Observer" tells a teammate the whole shape at once.

Tip: For interviews, prepare one real example per pattern, plus how Spring uses it (Proxy for @Transactional is a favourite follow-up).

Common design patterns

Explanation

Why patterns?

Singleton: exactly one instance

Factory: hide which class is created

Builder: many optional fields

Strategy: swap an algorithm

Observer: notify many listeners

Need help?

Watch the lesson

In real life: Payment strategies at checkout

Practice (0/3 done)

Quick quiz

Read more (free)

Before this, learn

Related topics

Next steps

Common design patterns

Explanation

Why patterns?

Singleton: exactly one instance

Factory: hide which class is created

Builder: many optional fields

Strategy: swap an algorithm

Observer: notify many listeners

Need help?

Watch the lesson

In real life: Payment strategies at checkout

Practice (0/3 done)

Quick quiz

Read more (free)

Related help

Before this, learn

Related topics

Questions people ask about this

Next steps