Behavioral patterns (Observer, Strategy, Command) in Software Engineering - Time & Space Complexity

Time Complexity: Behavioral patterns (Observer, Strategy, Command)

O(n)

Understanding Time Complexity

Behavioral design patterns help organize how objects interact and change behavior. Analyzing their time complexity shows how the cost of these interactions grows as the number of objects or commands increases.

We want to understand how the execution time changes when using Observer, Strategy, or Command patterns as the system grows.

Scenario Under Consideration

Analyze the time complexity of notifying observers in the Observer pattern.

class Subject:
    def __init__(self):
        self.observers = []

    def register(self, observer):
        self.observers.append(observer)

    def notify(self, message):
        for observer in self.observers:
            observer.update(message)

This code shows a subject notifying all registered observers by calling their update method.

Identify Repeating Operations

Look at what repeats when notify is called.

• Primary operation: Looping through all observers to call update.
• How many times: Once for each observer registered.

How Execution Grows With Input

As the number of observers grows, the notify method calls update more times.

Input Size (n)	Approx. Operations
10	10 update calls
100	100 update calls
1000	1000 update calls

Pattern observation: The number of operations grows directly with the number of observers.

Final Time Complexity

Time Complexity: O(n)

This means the time to notify observers grows linearly with how many observers there are.

Common Mistake

[X] Wrong: "Notifying observers happens instantly no matter how many there are."

[OK] Correct: Each observer must be updated one by one, so more observers mean more work and more time.

Interview Connect

Understanding how behavioral patterns affect time helps you explain design choices clearly. It shows you can think about both design and performance, a valuable skill in real projects.

Self-Check

What if the notify method used multiple threads to update observers in parallel? How would the time complexity change?

Practice

1. Which behavioral pattern is used when an object needs to notify multiple other objects about a change in its state?

easy

A. Command

B. Strategy

C. Observer

D. Singleton

Solution

1. Step 1: Understand the role of Observer pattern

   The Observer pattern allows one object (the subject) to notify many dependent objects (observers) automatically when its state changes.

2. Step 2: Compare with other patterns

   Strategy selects algorithms at runtime, Command encapsulates requests, and Singleton restricts instance creation. Only Observer fits the notification role.

3. Final Answer:

   Observer -> Option C

4. Quick Check:

   Notification to many = Observer [OK]

Hint: Notification to many objects? Think Observer pattern [OK]

Common Mistakes:

• Confusing Strategy with Observer
• Thinking Command handles notifications
• Mixing Singleton with behavioral patterns

2. Which of the following is the correct way to define a Command pattern interface in object-oriented design?

easy

A. An interface with a method like execute() to perform the action

B. A class that holds multiple algorithms to choose from

C. A subject that notifies observers about changes

D. A singleton class that manages global state

Solution

1. Step 1: Identify Command pattern structure

   The Command pattern encapsulates a request as an object, typically by defining an interface with an execute() method to perform the action.

2. Step 2: Eliminate other options

   A class that holds multiple algorithms to choose from describes Strategy, C describes Observer, and D describes Singleton, none of which define a command interface.

3. Final Answer:

   An interface with a method like execute() to perform the action -> Option A

4. Quick Check:

   Command interface = execute() method [OK]

Hint: Command pattern always has an execute() method [OK]

Common Mistakes:

• Confusing Command with Strategy interface
• Thinking Command notifies observers
• Mixing Singleton with Command

3. Consider this code snippet using the Strategy pattern:

class Context:
    def __init__(self, strategy):
        self.strategy = strategy
    def execute(self, data):
        return self.strategy.do_algorithm(data)

class StrategyA:
    def do_algorithm(self, data):
        return sorted(data)

class StrategyB:
    def do_algorithm(self, data):
        return sorted(data, reverse=True)

context = Context(StrategyA())
result = context.execute([3, 1, 2])
print(result)

What will be the output?

medium

A. [3, 1, 2]

B. [1, 2, 3]

C. [3, 2, 1]

D. TypeError

Solution

1. Step 1: Understand the Strategy pattern usage

   The Context uses StrategyA, whose do_algorithm method sorts the list in ascending order.

2. Step 2: Trace the execution

   Calling context.execute([3, 1, 2]) calls StrategyA.do_algorithm which returns [1, 2, 3].

3. Final Answer:

   [1, 2, 3] -> Option B

4. Quick Check:

   StrategyA sorts ascending = [1, 2, 3] [OK]

Hint: StrategyA sorts ascending, so output is sorted list [OK]

Common Mistakes:

• Assuming StrategyB is used
• Confusing sorting order
• Expecting original list unchanged

4. In the Observer pattern, what is the main issue if observers are not properly detached when no longer needed?

medium

A. Memory leaks due to lingering references

B. Strategy selection becomes unpredictable

C. Commands fail to execute

D. Singleton instance is duplicated

Solution

1. Step 1: Understand observer detachment importance

   If observers are not detached, the subject keeps references to them, preventing garbage collection.

2. Step 2: Identify consequence

   This causes memory leaks because unused observers remain in memory unnecessarily.

3. Final Answer:

   Memory leaks due to lingering references -> Option A

4. Quick Check:

   Undetached observers cause memory leaks [OK]

Hint: Undetached observers cause memory leaks [OK]

Common Mistakes:

• Confusing with Strategy or Command issues
• Thinking it causes command execution failure
• Assuming Singleton duplication

5. You want to design a system where users can perform different operations (like save, load, delete) on files, and you want to queue these operations to execute later or undo them if needed. Which behavioral pattern best fits this requirement and why?

hard

A. Singleton pattern, because it ensures only one file manager exists

B. Observer pattern, because it notifies users about file changes

C. Strategy pattern, because it selects the best file operation algorithm

D. Command pattern, because it encapsulates requests as objects allowing queuing and undo

Solution

1. Step 1: Analyze the requirement for queuing and undo

   Queuing operations and supporting undo requires encapsulating each request as an object to store and manage them flexibly.

2. Step 2: Match with behavioral patterns

   The Command pattern encapsulates requests as objects, enabling queuing, logging, and undo functionality. Observer and Strategy do not support queuing commands, and Singleton only controls instance creation.

3. Final Answer:

   Command pattern, because it encapsulates requests as objects allowing queuing and undo -> Option D

4. Quick Check:

   Queue and undo operations = Command pattern [OK]

Hint: Queue and undo operations? Use Command pattern [OK]

Common Mistakes:

• Choosing Observer for queuing commands
• Confusing Strategy with Command
• Selecting Singleton for operation management