Design Patterns Interview Questions with Answers Part 2

If you're new to design patterns or haven't gone through the basics yet, we highly recommend reading Part 1: Design Patterns Interview Questions and Answers first. It covers the core concepts, SOLID principles and the most commonly asked interview questions that provide the foundation for this advanced section.

Once you're comfortable with the fundamentals, continue with Part 2 to explore more advanced interview scenarios, real-world applications, pattern comparisons and enterprise-level design concepts.

1. What Problem Does the Builder Pattern Solve That Constructors Cannot?

The Builder Pattern is a Creational Design Pattern that solves the problem of creating complex objects with many required and optional parameters. As the number of constructor parameters increases, constructors become difficult to read, maintain and use correctly, a problem commonly known as the Telescoping Constructor Anti-Pattern.

Instead of passing numerous parameters to a constructor, the Builder Pattern constructs an object step by step, allowing only the required properties to be specified while keeping optional properties flexible.

When Should You Use the Builder Pattern?

Use the Builder Pattern when:

• An object has many optional parameters.
• Constructors become overloaded with multiple parameter combinations.
• Objects need to be created in a specific sequence.
• You want to create immutable objects.
• Object creation logic should be separated from the object's representation.

Advantages of the Builder Pattern

• Eliminates telescoping constructors.
• Improves code readability and maintainability.
• Supports fluent method chaining.
• Allows step-by-step object construction.
• Makes object creation less error-prone.

Example

Suppose you're creating a Computer object. Some properties are required:

• Processor
• Motherboard

Others are optional:

• RAM
• SSD
• Graphics Card (GPU)
• Wi-Fi Adapter
• RGB Lighting

Instead of writing constructors with many parameters:

Computer(cpu, motherboard, ram, ssd, gpu, wifi, rgb, ...)

the Builder Pattern allows clean and readable object creation:

Computer.builder()
        .processor("Intel i9")
        .ram("32 GB")
        .ssd("1 TB")
        .gpu("RTX 5080")
        .build();

Only the required and desired optional fields are specified, making the code much easier to understand.

Interview Tip: The Builder Pattern is commonly used in modern APIs such as StringBuilder, HttpRequest.Builder (Java) and many ORM and cloud SDKs that rely on fluent APIs.

2. How Does the Prototype Pattern Differ from Object Cloning Using clone() in Java?

Although both the Prototype Pattern and Java's clone() mechanism create copies of existing objects, they operate at different levels of abstraction and solve different problems.

The Prototype Pattern is a Creational Design Pattern that provides a controlled and reusable way to create new objects by copying existing prototype instances. It hides the cloning logic behind an interface and allows applications to decide whether a shallow copy or a deep copy is required.

Java's clone() method, on the other hand, is a low-level object-copying mechanism that requires implementing the Cloneable interface. It often results in shallow copies unless developers manually implement deep-copy behavior.

Prototype Pattern vs. clone()

Example

Consider a video game where different enemy characters share common properties. Instead of constructing every enemy from scratch, the game creates a prototype enemy and copies it whenever a new enemy is required.

The Prototype Pattern ensures that nested objects such as weapons, inventory or health status are copied correctly.

Using Java's default clone() implementation without deep copying could cause multiple enemies to unintentionally share the same weapon or inventory object.

Interview Tip: Since Java's clone() API has several design limitations, many modern Java applications prefer copy constructors, factory methods or dedicated cloning libraries instead of relying directly on clone().

3. When Should the Abstract Factory Pattern Be Preferred Over the Factory Method Pattern?

Both the Abstract Factory Pattern and the Factory Method Pattern are Creational Design Patterns, but they solve different object creation problems.

• Use the Factory Method Pattern when you need to create a single type of product.

• Use the Abstract Factory Pattern when you need to create families of related or compatible objects that should work together.

When Should You Choose the Abstract Factory Pattern?

The Abstract Factory Pattern is the better choice when:

• Multiple related objects must be created together.
• Products within the same family must remain compatible.
• The application should support switching entire product families.
• Client code should remain independent of concrete implementations.

Abstract Factory vs. Factory Method

Example

Consider a cross-platform UI framework. The application supports two operating systems:

• Windows
• macOS

Each platform requires multiple compatible UI components:

• Button
• Checkbox
• Menu
• Text Field

The Abstract Factory Pattern creates an entire family of compatible UI components. For example:

Windows Factory

• Windows Button
• Windows Menu
• Windows Checkbox

macOS Factory

• macOS Button
• macOS Menu
• macOS Checkbox

Switching from Windows to macOS simply requires selecting a different factory, while the client code remains unchanged.

In contrast, the Factory Method Pattern would typically create only a single component, such as a Button, rather than an entire family of related UI elements.

Interview Tip: A simple way to remember the difference is:

• Factory Method = One product.
• Abstract Factory = A family of related products.

4. What Are the Disadvantages of Using the Singleton Pattern?

Although the Singleton Pattern ensures that only one instance of a class exists, it can introduce several design challenges if used excessively or in inappropriate situations.

Singletons effectively introduce global state, which increases coupling between components and can make applications more difficult to test, maintain and extend.

Disadvantages of the Singleton Pattern

• Creates a global point of access that can hide dependencies.
• Increases coupling between application components.
• Makes unit testing more difficult because replacing the singleton with a mock object is challenging.
• Can violate the Single Responsibility Principle (SRP) by combining object creation with business logic.
• Requires additional synchronization in multithreaded applications when using lazy initialization.
• Makes dependency management harder in large applications.

Example

Consider a Singleton Database Connection Manager. Every class directly accesses the singleton instance. During unit testing, replacing the real database connection with a mock implementation becomes difficult because all classes depend on the same global instance.

Modern applications often prefer Dependency Injection (DI) over Singleton because dependencies can easily be substituted during testing.

Interview Tip: Singleton is useful for shared resources such as configuration managers or loggers, but avoid using it as a replacement for proper dependency management.

5. How Does the Lazy Initialization Technique Work in the Singleton Pattern?

Lazy Initialization delays the creation of a Singleton object until it is actually needed, instead of creating it when the application starts. This improves startup performance and avoids allocating memory for objects that may never be used.

How Lazy Initialization Works

1. The singleton instance is initially null.
2. The first call to getInstance() creates the object.
3. Subsequent calls return the existing instance.

Advantages

• Reduces startup time.
• Saves memory by creating objects only when required.
• Avoids unnecessary initialization of expensive resources.

Considerations

In multithreaded applications, lazy initialization must be implemented carefully to avoid creating multiple instances simultaneously.

Common thread-safe implementations include:

• Synchronized methods
• Double-Checked Locking
• Bill Pugh Singleton
• Enum Singleton (Java)

Example

A logging service may never be used in some application executions. Instead of creating the logger during application startup, it is instantiated only when the first log message is written.

Interview Tip: Lazy Initialization improves performance but requires thread-safe implementation in concurrent applications.

6. Explain the Difference Between Composition and Inheritance with Respect to Design Patterns.

Composition and Inheritance are two techniques for reusing code, but modern design patterns generally prefer composition over inheritance because it offers greater flexibility and lower coupling.

Composition vs. Inheritance

Example

The Strategy Pattern uses composition.

A PaymentContext object delegates payment processing to different strategy implementations such as:

• Credit Card Payment
• UPI Payment
• PayPal Payment

The payment method can be changed dynamically without modifying the context class.

Using inheritance would require creating separate subclasses for every payment variation, making the hierarchy difficult to maintain.

Interview Tip: One of the most famous object-oriented design principles is "Favor Composition Over Inheritance."

7. What Role Does Encapsulation Play in Implementing Behavioral Design Patterns?

Encapsulation is a fundamental object-oriented principle that hides implementation details while exposing only the required behavior. Behavioral design patterns rely heavily on encapsulation to separate what an object does from how it performs the task.

Benefits of Encapsulation in Behavioral Patterns

• Hides implementation complexity.
• Promotes loose coupling.
• Allows behavior to change without affecting client code.
• Improves maintainability and extensibility.
• Makes classes easier to test independently.

Example

In the Command Pattern, each command object encapsulates:

• The request
• The receiver
• The execution logic

The caller simply invokes the command without knowing how the action is performed internally.

Similarly, the Strategy Pattern encapsulates different algorithms behind a common interface, allowing the client to switch strategies without changing its code.

Interview Tip: Encapsulation is one of the key reasons behavioral patterns remain flexible and interchangeable.

8. Explain How the Facade Pattern Simplifies Complex Subsystems.

The Facade Pattern is a Structural Design Pattern that provides a single, simplified interface to a complex subsystem. Instead of interacting with multiple subsystem classes, clients communicate only with the facade, which coordinates the required operations internally.

Benefits of the Facade Pattern

• Hides subsystem complexity.
• Reduces coupling between clients and subsystem classes.
• Simplifies application usage.
• Improves readability and maintainability.
• Centralizes interactions with multiple components.

Example

Consider a Home Theater System. Without a facade, a client must individually operate:

• Projector
• Sound System
• DVD Player
• Streaming Device
• Lights

A HomeTheaterFacade exposes simple methods such as:

• watchMovie()
• stopMovie()

Internally, it coordinates all subsystem components automatically.

Interview Tip: A Facade simplifies an existing subsystem, whereas an Adapter makes incompatible interfaces work together.

9. In What Scenarios Is the Flyweight Pattern Most Effective?

The Flyweight Pattern is a Structural Design Pattern used to reduce memory consumption by sharing common data among a large number of similar objects. Instead of storing duplicate information inside every object, shared data is stored once and reused.

When Should You Use the Flyweight Pattern?

Use the Flyweight Pattern when:

• The application creates a very large number of similar objects.
• Memory consumption becomes a concern.
• Objects contain substantial shared state.
• Shared (intrinsic) data can be separated from unique (extrinsic) data.

Example

A text editor may display millions of characters. Instead of storing font information, color and style inside every character object, these properties are shared using Flyweight objects.

Each character stores only unique information such as:

• Character value
• Cursor position
• Line number

This significantly reduces memory usage.

Interview Tip: Flyweight separates Intrinsic State (shared) from Extrinsic State (unique)—a favorite interview question.

10. How Does the Proxy Pattern Differ from the Decorator Pattern?

Although both the Proxy Pattern and Decorator Pattern wrap another object, they have different purposes.

The Proxy Pattern controls access to an object, while the Decorator Pattern adds new functionality without modifying the original object.

Proxy vs. Decorator

Example

Proxy

A file proxy checks whether the current user has permission before allowing access to the actual file.

Decorator

A file decorator adds compression, encryption or logging while preserving the original file functionality.

Interview Tip: Proxy protects, while Decorator enhances.

11. What Problem Does the Chain of Responsibility Pattern Solve?

The Chain of Responsibility Pattern is a Behavioral Design Pattern that allows multiple objects to process a request without the sender knowing which object will handle it. Instead of directly calling one handler, the request passes through a chain until one of the handlers processes it.

Benefits

• Reduces coupling between sender and receiver.
• Supports dynamic request handling.
• Makes adding new handlers simple.
• Improves flexibility.

Example

Consider an expense approval workflow. A reimbursement request moves through:

• Team Lead
• Manager
• Director
• CEO

Each approver decides whether to handle the request or forward it to the next approver. The requester does not need to know who ultimately approves it.

Interview Tip: Chain of Responsibility is commonly used in approval workflows, HTTP middleware and exception handling pipelines.

12. How Does the Mediator Pattern Reduce Coupling Between Objects?

The Mediator Pattern is a Behavioral Design Pattern that centralizes communication between multiple objects through a single mediator.

Instead of objects communicating directly with each other, they interact only with the mediator.

This significantly reduces dependencies and simplifies communication.

Benefits of the Mediator Pattern

• Reduces direct coupling between objects.
• Centralizes communication logic.
• Simplifies object interactions.
• Improves maintainability.
• Makes it easier to add new participants.

Example

Consider a group chat application.

• Without a mediator: Every user communicates directly with every other user.

• With a mediator: Each user sends messages only to the ChatMediator, which forwards them to the appropriate recipients.

Users never reference one another directly, making the system easier to maintain and extend.

Interview Tip: A simple way to remember the pattern is:

Observer = One-to-Many Notifications

Mediator = Many-to-Many Communication Managed by One Object

13. What Are the Key Components of the Observer Pattern?

The Observer Pattern is a Behavioral Design Pattern that establishes a one-to-many relationship between objects. Whenever the state of one object changes, all dependent objects are automatically notified and updated.

This pattern is commonly used in event-driven systems, GUI frameworks and publish-subscribe architectures.

Key Components of the Observer Pattern

• Subject (Publisher) – Maintains a list of observers and notifies them whenever its state changes.
• Observer Interface – Defines the update() method that all observers must implement.
• Concrete Subject – Stores the state and triggers notifications when the state changes.
• Concrete Observer – Implements the update behavior and reacts to notifications from the subject.

Example

Consider a stock market application.

• The Stock object acts as the Subject.
• Multiple displays, mobile apps and dashboards act as Observers.

Whenever the stock price changes, the Subject automatically notifies every registered observer, ensuring all displays remain synchronized.

Interview Tip: The Observer Pattern is one of the most common patterns used in event-driven programming, where one object needs to notify many dependent objects about state changes.

14. How Does the Strategy Pattern Support the Open/Closed Principle?

The Strategy Pattern supports the Open/Closed Principle (OCP) by allowing new algorithms or behaviors to be introduced without modifying existing code.

Instead of changing the context class whenever a new algorithm is needed, developers simply create a new strategy class that implements the common strategy interface.

How It Supports OCP

• New strategies are added by creating new classes.
• Existing strategy implementations remain unchanged.
• The context depends only on the strategy interface.
• New functionality is introduced through extension rather than modification.

Example

Consider an e-commerce checkout system. Initially, the application supports:

• Credit Card
• UPI

Later, support for:

• PayPal
• Cryptocurrency

can be added by creating new strategy classes. The checkout logic remains unchanged because it interacts only with the PaymentStrategy interface.

Interview Tip: The Strategy Pattern is one of the best examples of the Open/Closed Principle because new algorithms can be added without modifying the context class.

15. What Is the Role of Context in the Strategy Pattern?

In the Strategy Pattern, the Context is the class that holds a reference to a strategy object and delegates the execution of an algorithm to that strategy.

The Context does not know how the algorithm is implemented. It simply invokes the selected strategy through a common interface.

Responsibilities of the Context

• Maintains a reference to the active strategy.
• Delegates algorithm execution to the selected strategy.
• Allows the strategy to be changed at runtime.
• Remains independent of concrete strategy implementations.

Example

In an online payment system:

• Checkout acts as the Context.
• CreditCardPayment, UPIPayment and NetBankingPayment are different Strategy implementations.

The Checkout class delegates payment processing to whichever strategy is currently selected.

Interview Tip: The Context is responsible for using a strategy—not implementing it.

16. When Is the Visitor Pattern Useful Despite Its Complexity?

The Visitor Pattern is most useful when the object structure remains stable, but new operations need to be added frequently.

Instead of modifying every class whenever a new operation is introduced, developers create a new Visitor class containing the additional behavior.

When Should You Use the Visitor Pattern?

Use the Visitor Pattern when:

• The object hierarchy changes rarely.
• New operations are added frequently.
• Operations should be separated from the object structure.
• Multiple unrelated operations need to be performed on the same objects.

Example

A compiler stores its program as an Abstract Syntax Tree (AST).

Different visitors perform operations such as:

• Type Checking
• Code Generation
• Optimization
• Syntax Validation

The AST node classes remain unchanged while new compiler operations are added as separate Visitor implementations.

Interview Tip: Visitor makes adding new operations easy but makes adding new object types more difficult.

17. How Does the State Pattern Differ from the Strategy Pattern?

Although both patterns use composition, they solve different problems.

The State Pattern changes an object's behavior automatically when its internal state changes.

The Strategy Pattern allows the client to choose which algorithm should be used.

State Pattern vs. Strategy Pattern

Example

State Pattern

A vending machine changes behavior depending on its current state:

• No Coin
• Coin Inserted
• Product Dispensed

The user does not manually select the state.

Strategy Pattern

A payment system allows users to choose:

• Credit Card
• UPI
• PayPal

The client explicitly selects the desired payment strategy.

Interview Tip: State = Internal behavior changes automatically. Strategy = Client chooses the algorithm.

18. Explain How the Command Pattern Supports Undo and Redo Functionality.

The Command Pattern encapsulates each user action as a command object. Because every command contains the information required to execute and reverse an operation, applications can easily implement Undo and Redo functionality.

How It Works

1. A user action creates a command object.
2. The command executes the requested operation.
3. The command is stored in a history stack.
4. Undo invokes the command's reverse operation.
5. Redo executes the command again.

Example

In a text editor:

• Typing text
• Deleting text
• Pasting content

are represented as individual command objects.

Undo reverses the most recent command, while Redo re-executes it.

Interview Tip: The Command Pattern is widely used in editors, IDEs, drawing applications and productivity software because it naturally supports Undo, Redo, macro recording and command history.

19. How Is the Template Method Pattern Different from the Strategy Pattern?

Both patterns define algorithms, but they use different techniques.

• The Template Method Pattern uses inheritance to allow subclasses to customize specific steps of an algorithm while preserving its overall structure.

• The Strategy Pattern uses composition to allow completely different algorithms to be selected at runtime.

Template Method vs. Strategy

Example

A data import framework always performs these steps:

1. Read File
2. Validate Data
3. Process Records
4. Save Results

• With the Template Method Pattern, subclasses customize only the validation or processing steps.

• Using the Strategy Pattern, the entire processing algorithm could be replaced at runtime.

Interview Tip: Template Method = Inheritance. Strategy = Composition.

20. What Design Pattern Is Commonly Used in Logging Frameworks and Why?

The Singleton Pattern is commonly used in logging frameworks because only one shared logger instance is typically required throughout an application.

A shared logger ensures that all components write logs consistently while avoiding unnecessary object creation.

Why Singleton Is Used

• Ensures one shared logging instance.
• Provides a centralized access point.
• Prevents inconsistent logging behavior.
• Reduces memory usage.

Example

Different services in an application call:

• Authentication Service
• Payment Service
• Order Service

All use the same Logger instance to write messages to a common log file.

Interview Tip: Modern dependency injection frameworks may manage logger lifecycles without explicitly implementing the Singleton Pattern, although the underlying behavior is often singleton-like.

21. What Are Anti-Patterns and How Do They Differ from Design Patterns?

Anti-patterns describe commonly used solutions that appear helpful initially but ultimately lead to poor software design, maintenance issues or reduced performance.

Design patterns, in contrast, are proven best practices that solve recurring software design problems effectively.

Design Patterns vs. Anti-Patterns

Example

A God Object is a common anti-pattern. One class performs:

• Business Logic
• Database Access
• Validation
• Logging
• UI Handling

This violates the Single Responsibility Principle.

Applying patterns such as Facade, Strategy or Command distributes responsibilities across multiple classes, resulting in cleaner and more maintainable code.

Interview Tip: Interviewers often ask about anti-patterns such as God Object, Spaghetti Code, Golden Hammer and Copy-Paste Programming.

22. How Do Design Patterns Help in Achieving Loose Coupling?

One of the primary goals of design patterns is to reduce direct dependencies between software components.

Instead of communicating with concrete implementations, classes interact through interfaces or abstract classes, making applications easier to modify, extend and test.

Benefits of Loose Coupling

• Improves maintainability.
• Simplifies testing.
• Supports extensibility.
• Encourages modular architecture.
• Reduces ripple effects when changes occur.

Design Patterns That Promote Loose Coupling

• Strategy Pattern
• Observer Pattern
• Factory Method
• Abstract Factory
• Dependency Injection
• Mediator Pattern

Example

In the Observer Pattern, the Subject depends only on the Observer interface.

New observers can be added or removed without modifying the Subject. This keeps both components loosely coupled and independently maintainable.

Interview Tip: Loose coupling is one of the main objectives of the SOLID principles and most GoF Design Patterns.

13. Can Multiple Design Patterns Be Combined in a Single Solution? Provide Examples.

Yes. In real-world software systems, multiple design patterns are often combined because each pattern solves a different aspect of a design problem.

Combining patterns results in software that is more modular, flexible, scalable and maintainable.

Benefits of Combining Design Patterns

• Separates responsibilities effectively.
• Improves scalability.
• Encourages reusable architecture.
• Supports SOLID principles.
• Makes complex systems easier to maintain.

Common Pattern Combinations

Example

A typical MVC (Model-View-Controller) application may combine several design patterns:

• Observer Pattern – Updates the View whenever the Model changes.
• Strategy Pattern – Encapsulates interchangeable business rules.
• Factory Pattern – Creates controllers, services or repositories.
• Singleton Pattern – Manages shared configuration or logging services.

Each pattern addresses a different concern, resulting in a clean and extensible architecture.

Interview Tip: Professional software systems rarely rely on a single design pattern. Enterprise applications commonly combine multiple patterns to solve different architectural and behavioral challenges.

14. What Factors Should Be Considered Before Choosing a Design Pattern?

Choosing the right design pattern requires understanding the problem you are trying to solve rather than forcing a pattern into every design. A design pattern should simplify the architecture, not make it unnecessarily complex. Before selecting a design pattern, evaluate both the current requirements and the application's future scalability and maintainability.

Factors to Consider

• Nature of the Problem – Identify the actual design challenge before selecting a pattern.
• System Complexity – Avoid introducing patterns that add unnecessary abstraction.
• Future Changes – Consider how often the feature or business logic is expected to evolve.
• Maintainability – Choose patterns that improve readability and long-term maintenance.
• Performance – Some patterns introduce additional objects or indirection that may impact performance.
• Flexibility and Extensibility – Ensure the pattern allows new functionality to be added easily.
• Team Familiarity – Prefer patterns your development team can understand and maintain effectively.
• SOLID Principles – Select patterns that encourage loose coupling and clean architecture.

Example

Suppose an application needs a shared configuration service. A Singleton Pattern may initially appear to be the simplest solution.

However, if the application requires dependency injection, unit testing or multiple environments, using Dependency Injection (DI) instead of a Singleton may provide greater flexibility and testability.

Interview Tip: Interviewers are often more interested in why you chose a pattern than which pattern you chose. Always explain the design problem the pattern solves.

15. How Do Design Patterns Improve Testability of Code?

Design patterns improve testability by promoting loose coupling, separation of concerns and dependency abstraction. Instead of depending directly on concrete implementations, classes communicate through interfaces, allowing dependencies to be replaced with mocks, stubs or fake implementations during testing.

How Design Patterns Improve Testability

• Separate responsibilities into smaller components.
• Reduce dependencies between classes.
• Allow dependencies to be mocked during unit testing.
• Encourage dependency injection.
• Improve isolation of business logic.
• Simplify automated testing.

Design Patterns That Improve Testability

• Strategy Pattern
• Factory Method
• Observer Pattern
• Dependency Injection
• Command Pattern
• Mediator Pattern

Example

Consider the Strategy Pattern.

A PaymentContext depends only on the PaymentStrategy interface. During testing, a MockPaymentStrategy can be injected to verify business logic without communicating with external payment gateways.

Interview Tip: Highly coupled classes are difficult to test. Most GoF design patterns aim to reduce coupling, making automated testing significantly easier.

26. How Do Design Patterns Evolve with Changing Software Requirements?

Design patterns are not permanent architectural decisions. As applications evolve, design patterns may be adapted, combined, refactored or even removed to better satisfy new requirements.

Modern programming languages and frameworks also provide built-in features that reduce the need for certain traditional design patterns.

How Design Patterns Evolve

• Existing patterns may be combined with other patterns.
• Simpler solutions may replace unnecessary patterns.
• Framework features can eliminate boilerplate implementations.
• New architectural styles may require different patterns.
• Patterns should evolve with changing business requirements.

Example

Earlier enterprise applications frequently used the Singleton Pattern for shared services. Modern frameworks such as Spring and ASP.NET Core typically manage object lifecycles through Dependency Injection, improving flexibility, scalability and testability.

Similarly, newer language features such as lambdas, records and pattern matching have simplified implementations of several classic GoF patterns.

Interview Tip: Design patterns should evolve alongside the application. They are architectural tools—not fixed rules.

27. How Does the Null Object Pattern Help Eliminate Null Checks in Code?

The Null Object Pattern replaces null references with a special object that implements the same interface but performs a safe default or "do nothing" behavior. Instead of repeatedly checking whether an object is null, client code interacts with the Null Object exactly like any other implementation.

Benefits of the Null Object Pattern

• Eliminates repetitive null checks.
• Reduces the risk of NullPointerException.
• Simplifies client code.
• Improves readability.
• Preserves polymorphism by treating all implementations uniformly.

Example

Suppose an application uses a Logger interface. Instead of writing:

if (logger != null) {
    logger.log("Application Started");
}

the application injects a NullLogger.

Calling:

logger.log("Application Started");

does nothing, eliminating conditional logic while keeping the client code clean.

Interview Tip: The Null Object Pattern is especially useful when the absence of behavior is itself a valid behavior.

28. What Is the Difference Between Static Factory Methods and the Factory Pattern?

Although both create objects, Static Factory Methods and the Factory Pattern solve different problems.

A Static Factory Method is simply a static method that returns an object.

The Factory Pattern is a design pattern that abstracts object creation through interfaces or abstract classes, allowing different implementations to be created without changing client code.

Static Factory Method vs. Factory Pattern

Example

Static Factory Method

User user = User.createUser();

Factory Pattern

UserFactory factory = new PremiumUserFactory();
User user = factory.createUser();

Adding a new user type requires only a new factory implementation, leaving existing client code unchanged.

Interview Tip: Static Factory Methods are language features, while the Factory Pattern is an architectural design pattern.

29. How Does the Iterator Pattern Support Encapsulation?

The Iterator Pattern provides a way to traverse the elements of a collection without exposing its internal representation. Clients use an iterator instead of directly accessing the collection's underlying data structure.

This preserves encapsulation by hiding implementation details.

Benefits of the Iterator Pattern

• Hides internal collection structure.
• Separates traversal logic from collection implementation.
• Supports multiple traversal algorithms.
• Simplifies collection usage.
• Improves maintainability.

Example

Suppose a custom collection stores data internally using:

• Array
• Linked List
• Binary Tree

Regardless of the underlying implementation, clients simply use an iterator:

Iterator<Employee> iterator = employees.iterator();

The client never needs to know how the collection stores its data.

Interview Tip: The Java Collections Framework (Iterator and ListIterator) is one of the most common real-world implementations of the Iterator Pattern.

30. When Is the Memento Pattern Preferred for State Management?

The Memento Pattern is a Behavioral Design Pattern used when an object's state needs to be saved and restored without exposing its internal implementation. It allows applications to capture a snapshot of an object's state and restore it later while preserving encapsulation.

When Should You Use the Memento Pattern?

Use the Memento Pattern when:

• Undo and Redo functionality is required.
• Object snapshots must be preserved.
• State restoration is needed.
• Internal object details should remain hidden.
• Application history must be maintained.

Example

A text editor periodically saves the current document state as a series of Memento objects.

When the user clicks Undo, the editor restores the previous snapshot without exposing or modifying the document's internal data structure directly.

Other common examples include:

• Drawing applications
• Game save systems
• Version history
• Workflow rollback
• Database transaction recovery

Advantages

• Preserves encapsulation.
• Supports Undo and Redo functionality.
• Simplifies state restoration.
• Keeps snapshot management separate from business logic.

Disadvantages

• Can consume significant memory when storing many snapshots.
• Managing large histories may impact performance.

Interview Tip: The Memento Pattern consists of three participants:

• Originator – The object whose state is saved.
• Memento – Stores the snapshot of the object's state.
• Caretaker – Manages the history of mementos without modifying their contents.