When to use which behavioral pattern in LLD - System Design Exercise

Design: Behavioral Design Patterns Usage Guide

In scope: behavioral design patterns explanation and usage scenarios. Out of scope: code implementation details, structural or creational patterns.

Functional Requirements

FR1: Explain common behavioral design patterns

FR2: Describe scenarios where each pattern is most useful

FR3: Provide guidance on choosing the right pattern based on problem context

FR4: Include examples of real-life situations for each pattern

Non-Functional Requirements

NFR1: Focus on clarity and simplicity for beginners

NFR2: Avoid technical jargon

NFR3: Patterns must be relevant to common software design problems

NFR4: Guide should be applicable to low-level design (LLD)

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Objects representing roles in patterns (e.g., Observer, Command, State)

Interfaces or abstract classes defining behavior contracts

Context objects holding state or managing interactions

Event or message dispatching mechanisms

Design Patterns

Strategy - for interchangeable algorithms

Observer - for event subscription and notification

Command - for encapsulating requests

State - for managing object states and transitions

Chain of Responsibility - for passing requests along a chain

Mediator - for centralizing complex communications

Iterator - for sequential access to collections

Template Method - for defining skeleton of an algorithm

Visitor - for operations on object structures

Reference Architecture

Behavioral Patterns Usage Guide

+-------------------+       +-------------------+
| Problem Scenario  |-----> | Identify Pattern  |
+-------------------+       +-------------------+
          |                            |
          v                            v
+-------------------+       +-------------------+
| Pattern Selection  |-----> | Apply Pattern     |
+-------------------+       +-------------------+
          |                            |
          v                            v
+-------------------+       +-------------------+
| Example Scenario   |-----> | Benefits & Tradeoffs|
+-------------------+       +-------------------+

Components

Strategy Pattern

Conceptual

Choose an algorithm at runtime from a family of algorithms.

Observer Pattern

Conceptual

Notify multiple objects about state changes in another object.

Command Pattern

Conceptual

Encapsulate a request as an object to parameterize clients.

State Pattern

Conceptual

Allow an object to alter its behavior when its internal state changes.

Chain of Responsibility Pattern

Conceptual

Pass a request along a chain of handlers until one handles it.

Mediator Pattern

Conceptual

Centralize complex communication between objects.

Iterator Pattern

Conceptual

Provide a way to access elements of a collection sequentially.

Template Method Pattern

Conceptual

Define the skeleton of an algorithm, deferring steps to subclasses.

Visitor Pattern

Conceptual

Separate an algorithm from the object structure it operates on.

Request Flow

1. 1. Identify the problem scenario requiring behavioral design.

2. 2. Analyze if behavior needs to change dynamically or if communication is complex.

3. 3. Match the scenario to a behavioral pattern based on intent and problem.

4. 4. Apply the chosen pattern to structure object interactions.

5. 5. Observe benefits like flexibility, decoupling, and easier maintenance.

Database Schema

Not applicable for this conceptual guide.

Scaling Discussion

Bottlenecks

Overusing patterns can lead to unnecessary complexity.

Choosing wrong pattern may cause rigid or inefficient design.

Complex communication patterns can become hard to maintain at scale.

Solutions

Use patterns only when they clearly solve a problem.

Evaluate tradeoffs before selecting a pattern.

Refactor and simplify communication paths as system grows.

Combine patterns thoughtfully to balance flexibility and simplicity.

Interview Tips

Time: Spend 10 minutes understanding the problem, 20 minutes discussing pattern options and their fit, 10 minutes explaining tradeoffs and examples, 5 minutes for questions.

Explain the problem context clearly before choosing a pattern.

Describe why a particular behavioral pattern fits the scenario.

Discuss benefits like decoupling, flexibility, and maintainability.

Mention tradeoffs and when not to use a pattern.

Use simple real-life analogies to illustrate pattern usage.

Practice

1. Which behavioral pattern is best suited when you want multiple objects to be notified automatically when one object changes its state?

easy

A. Observer pattern

B. Strategy pattern

C. Command pattern

D. Chain of Responsibility pattern

Solution

1. Step 1: Understand the need for automatic notifications

   The problem requires multiple objects to be updated when one object changes state, which means a one-to-many dependency.

2. Step 2: Match the pattern to the problem

   The Observer pattern is designed exactly for this: it lets observers subscribe to an object and get notified on changes.

3. Final Answer:

   Observer pattern -> Option A

4. Quick Check:

   Change notification = Observer [OK]

Hint: Notifications to many? Use Observer pattern [OK]

Common Mistakes:

• Confusing Strategy with Observer
• Using Command for notifications
• Choosing Chain of Responsibility for updates

2. Which pattern allows you to change an object's behavior at runtime by switching between different algorithms or strategies?

easy

A. Observer pattern

B. Strategy pattern

C. Command pattern

D. Chain of Responsibility pattern

Solution

1. Step 1: Identify the need for interchangeable behaviors

   The question asks about changing behavior dynamically, which means selecting algorithms or methods at runtime.

2. Step 2: Select the pattern that supports behavior switching

   The Strategy pattern encapsulates algorithms and lets you swap them easily without changing the client code.

3. Final Answer:

   Strategy pattern -> Option B

4. Quick Check:

   Change behavior dynamically = Strategy [OK]

Hint: Switch algorithms easily? Use Strategy pattern [OK]

Common Mistakes:

• Mixing Strategy with Observer
• Using Command for behavior changes
• Choosing Chain of Responsibility incorrectly

3. Consider this scenario: You have a request that can be handled by multiple objects in a chain. Each object decides if it can handle the request or passes it on. Which pattern fits this design?
Request -> Handler1 -> Handler2 -> Handler3

medium

A. Command pattern

B. Strategy pattern

C. Observer pattern

D. Chain of Responsibility pattern

Solution

1. Step 1: Analyze the request handling flow

   The request passes through a chain of handlers, each deciding to handle or forward it.

2. Step 2: Identify the matching behavioral pattern

   The Chain of Responsibility pattern allows multiple objects to handle a request in sequence until one handles it.

3. Final Answer:

   Chain of Responsibility pattern -> Option D

4. Quick Check:

   Request passes chain = Chain of Responsibility [OK]

Hint: Request passes chain? Use Chain of Responsibility [OK]

Common Mistakes:

• Confusing Chain with Command
• Using Observer for request handling
• Choosing Strategy incorrectly

4. You have a system where commands need to be queued, logged, and executed later. Which behavioral pattern should you use? Identify the error in this choice:
Using Observer pattern to queue commands.

medium

A. Incorrect, use Command pattern instead

B. Incorrect, use Chain of Responsibility instead

C. Incorrect, use Strategy pattern instead

D. Correct use of Observer

Solution

1. Step 1: Understand the requirement for queuing and executing commands

   Queuing, logging, and executing commands later requires encapsulating requests as objects.

2. Step 2: Identify the pattern that encapsulates requests

   The Command pattern encapsulates requests as objects, allowing queuing and deferred execution.

3. Step 3: Identify the error in using Observer

   Observer is for notifications, not for command encapsulation or queuing.

4. Final Answer:

   Incorrect, use Command pattern instead -> Option A

5. Quick Check:

   Queue commands = Command pattern [OK]

Hint: Queue commands? Use Command, not Observer [OK]

Common Mistakes:

• Using Observer for command queuing
• Confusing Command with Strategy
• Choosing Chain of Responsibility wrongly

5. You are designing a notification system where users can subscribe to different event types, and the system should allow adding new event types without changing existing code. Which combination of behavioral patterns is best suited?

hard

A. Chain of Responsibility for subscriptions and Command for event handling

B. Command for subscriptions and Chain of Responsibility for event handling

C. Observer for subscriptions and Strategy for event handling

D. Strategy for subscriptions and Observer for event handling

Solution

1. Step 1: Identify the subscription mechanism

   Users subscribing to events fits the Observer pattern, which supports dynamic subscription and notification.

2. Step 2: Identify flexible event handling

   Strategy pattern allows interchangeable algorithms for handling different event types without changing existing code.

3. Step 3: Combine patterns for extensibility

   Using Observer for subscriptions and Strategy for event handling supports adding new event types easily and keeps code maintainable.

4. Final Answer:

   Observer for subscriptions and Strategy for event handling -> Option C

5. Quick Check:

   Subscribe = Observer, flexible handling = Strategy [OK]

Hint: Subscribe = Observer, flexible handling = Strategy [OK]

Common Mistakes:

• Mixing Command with subscriptions
• Using Chain of Responsibility for subscriptions
• Confusing Strategy with Observer roles