Java Patterns Interview Questions

Common patterns: Singleton, Factory, Strategy, Observer, Adapter, Decorator, Proxy, Builder, Template Method, and State.

class Singleton {
  private static Singleton instance = new Singleton();
  private Singleton() {
  }
  public static Singleton getInstance() {
    return instance;
  }
}
class Prototype implements Cloneable {
  public Object clone() throws CloneNotSupportedException {
    return super.clone();
  }
}

Singleton creates one instance (lazy or eager initialization, thread-safe), Prototype creates copies of existing objects; Singleton manages instance count, Prototype manages object cloning.

class Singleton {
  private static Singleton instance;
  public static synchronized Singleton getInstance() {
    if(instance == null) instance = new Singleton();
    return instance;
  }
}
Prototype p1 = new Prototype();
Prototype p2 = (Prototype) p1.clone();

Singleton violates SOLID principles: tight coupling, hard to test (difficult to mock), breaks single responsibility, and creates global mutable state. It complicates dependency injection and multi-threaded scenarios.

class Singleton {
  private static Singleton instance;
  private Singleton() {
  }
  public static Singleton getInstance() {
    if(instance == null) instance = new Singleton();
    return instance;
  }
}

Common design patterns include Singleton, Factory, Strategy, Observer, Decorator, Adapter, Builder, Template Method, and Proxy for solving recurring design problems.

Singleton, Factory, Builder, Observer, Strategy, Adapter, Decorator, Proxy, Template Method, Command, State, Chain of Responsibility patterns for different structural/behavioral needs.

Builder provides flexible step-by-step object construction with method chaining; Facade simplifies complex subsystem interactions by providing a unified interface to multiple components.

Design patterns lack flexibility for evolving requirements,over-engineering with unnecessary patterns increases complexity; patterns should solve actual problems, not be applied dogmatically.

Reusable solutions to common design problems: creational (Builder, Singleton), structural (Adapter, Decorator), behavioral (Strategy, Observer).

Used Factory and Builder for object creation, Strategy for business logic, Observer for event handling, and Decorator for cross-cutting concerns.

Singleton, Factory, Builder, Strategy, Decorator, Observer, and Repository patterns depending on use-case requirements.

Message queues (RabbitMQ, Kafka), REST/gRPC APIs, event buses, and pub-sub mechanisms for asynchronous inter-service communication.

Services communicate via REST APIs, message queues (async), gRPC for low-latency, or event-driven architectures with event buses.

Independent scaling, polyglot persistence, fault isolation, faster deployments, and team autonomy vs monolith's coupling and scaling limitations.

Synchronous REST/gRPC for tight coupling with timeouts, asynchronous messaging for decoupling, service mesh for observability, and circuit breakers for resilience.

The Command pattern itself executes quickly; if performance is critical, use a queue/thread pool structure to batch commands rather than execute individually.

Command pattern encapsulates requests as objects, enabling queuing, undo/redo, logging, and delayed execution independent of the invoker.

Yes, Command pattern is commonly used for undo/redo mechanisms, macro recording, request queuing, and asynchronous task execution in real applications.

Builder pattern separates construction logic from representation, handles complex multi-step object creation more readably, and supports fluent interface compared to multiple constructor overloads.

Queue or Stack structures process commands in FIFO/LIFO order efficiently, enabling Command pattern implementation through queued execution.

Command pattern encapsulates requests as objects, enabling queuing, logging, undo/redo functionality, and decoupling invoker from receiver.

Yes, extensively used in business logic services for encapsulating operations like payments, notifications, and audit logging as command objects.

Builder pattern allows flexible object construction with validation and readability, avoiding telescoping constructors and allowing partial initialization of complex objects.

Common patterns: Factory, Strategy, Observer, Decorator, Adapter, Template Method, Proxy, Chain of Responsibility, and Dependency Injection patterns.

Singleton pattern is used for stateless services, logging, database connections, caching, and configuration management where only one instance should exist application-wide.

Design patterns solve recurring problems: Singleton manages single instances, Factory simplifies object creation, Observer enables event handling, Strategy allows algorithm switching, Proxy controls access.

Design pattern characteristics: reusable solutions to common design problems, provide templates for code structure, improve maintainability, promote best practices, and facilitate communication between developers.

Design pattern types: Creational (object creation), Structural (object composition and relationships), Behavioral (communication between objects and responsibility distribution).

Main patterns: Singleton, Factory, Builder (Creational); Adapter, Decorator, Facade, Proxy (Structural); Observer, Strategy, Command, State, Template Method (Behavioral).

Creational patterns: Singleton (thread-safe instance), Factory (object creation abstraction), Builder (complex object construction), Prototype (cloning objects), Abstract Factory (family of related objects).

Structural patterns: Adapter (interface compatibility), Decorator (dynamic behavior addition), Facade (simplified interface), Proxy (controlled access), Bridge (abstraction decoupling), Composite (tree structures).

Behavioral patterns: Observer (event notification), Strategy (algorithm switching), State (object state changes), Command (action encapsulation), Iterator (collection traversal), Template Method (algorithm skeleton).

Antipattern is a proven ineffective solution; examples: God Object (too many responsibilities), Spaghetti Code (tangled logic), Circular dependencies, Premature optimization, Magic numbers/strings without constants.

Patterns solved problems like managing object creation complexity, reducing coupling between components, and enabling flexible behavior without modifying core classes.

Singleton for loggers, configuration managers, thread pools, and database connection pools where you need a single instance shared across the application.

Factory for object creation abstraction, Strategy for runtime behavior selection, Decorator for adding responsibilities dynamically, Observer for event-driven architectures.

Builder enables readable multi-parameter object construction, fluent APIs, immutability, and optional parameters; cleaner than telescoping constructors or setters.

Yes, used Command pattern for undo/redo operations, transaction queueing, and decoupling request senders from handlers in event-driven systems.

Command pattern encapsulates requests as objects, enabling queuing, logging, undo/redo, and separation of concerns between invoker and executor.

Strategy pattern can replace Command when you need runtime algorithm selection without request encapsulation, though both solve behavioral flexibility differently.

Microservices communicate via REST/HTTP, async messaging (RabbitMQ, Kafka), or gRPC depending on latency requirements, consistency needs, and topology.

Microservices provide independent scalability, technology diversity per service, fault isolation, and faster deployment cycles compared to monolithic architectures.

Organized interaction through API gateways for routing, service discovery (Eureka, Consul), event buses for async flows, and circuit breakers for resilience.

Used async messaging (Kafka, RabbitMQ) for eventual consistency, REST for synchronous calls where ordering matters, and event sourcing for audit trails.

Dependency Injection, Factory, Strategy, Observer, Circuit Breaker, and Saga patterns for coordinating distributed transactions across microservices.

Designed multi-tenant SaaS platforms and event-driven architectures with 100+ microservices; focused on minimizing coupling through clear contracts and async messaging.

Design patterns are reusable solutions to common problems in software design that provide templates for writing maintainable, scalable code. They represent best practices and help developers communicate solutions using standardized vocabulary.

Lack of patterns leads to code duplication, inconsistent architecture, and harder maintenance. Without patterns, developers reinvent solutions repeatedly, increasing bugs and development time.