Observer Pattern

# CHAPTER 13

Observer Pattern #

1. Introduction #

2. Learning Objectives #

• Define the intent and mechanics of the Observer (Pub/Sub) pattern.

• Identify the tight-coupling dangers of synchronous method calls.

• Understand the roles of the "Subject" (Publisher) and the "Observer" (Subscriber).

• Architect a decoupled Event-Driven system.

• Implement real-time notification arrays.

3. The Core Concept (Pub / Sub) #

• The Subject (The Publisher): The object that holds the interesting state. It maintains a list of "Subscribers" who want to know when it changes.

• The Observers (The Subscribers): The objects that want to be notified. They all implement a standard interface (e.g., update()).

• The Decoupling: The Publisher does not know *who* the Subscribers are. It just loops through its list and calls update() on everyone. If the InventoryService wants to know about orders, it subscribes. The OrderService never has to hardcode the word "Inventory."

4. Real-World Analogy #

5. Why is this critical? #

• Event Listeners in UI: (e.g., button.addEventListener('click', function)). The button is the Publisher; the function is the Subscriber.

• MVC Architecture: The Model (Subject) notifies the View (Observer) when the database changes.

• Distributed Event Buses: (e.g., Kafka, RabbitMQ). These are just massive, cloud-scale implementations of the Observer pattern.

6. UML Diagram #

[ Subject (Publisher) ] ------------------> [ <<Interface>> Observer ]
- observers: List[]                               + update(data)
+ attach(Observer)                                      ^
+ detach(Observer)                                      | (Implements)
+ notify() { loop observers->update() }                 |
                                            -------------------------
                                            |                       |
                                    [ ConcreteObserverA ]   [ ConcreteObserverB ]
                                      + update(data)          + update(data)

7. Code Example (PHP) #

<?php
// --- 1. The Observer Interface (Subscriber) ---
interface OrderObserver {
    public function update($orderData);
}

// --- 2. The Subject Interface (Publisher) ---
interface Subject {
    public function attach(OrderObserver $observer);
    public function detach(OrderObserver $observer);
    public function notify();
}

// --- 3. The Concrete Subject (The Checkout Process) ---
class OrderService implements Subject {
    private $observers = [];
    public $latestOrder;

    // Add a subscriber to the list
    public function attach(OrderObserver $observer) {
        $this->observers[] = $observer;
    }

    public function detach(OrderObserver $observer) {
        // Find and remove observer (simplified for example)
        $key = array_search($observer, $this->observers);
        if ($key !== false) unset($this->observers[$key]);
    }

    // The Magic: Loop and notify everyone!
    public function notify() {
        foreach ($this->observers as $observer) {
            $observer->update($this->latestOrder);
        }
    }

    // Business Logic
    public function placeOrder($item) {
        echo "\nOrderService: Order placed for $item.\n";
        $this->latestOrder = $item;
        $this->notify(); // Trigger the event!
    }
}

// --- 4. Concrete Observers (The Decoupled Services) ---
class EmailService implements OrderObserver {
    public function update($orderData) {
        echo "EmailService: Sending receipt for $orderData to customer.\n";
    }
}

class InventoryService implements OrderObserver {
    public function update($orderData) {
        echo "InventoryService: Deducting stock for $orderData.\n";
    }
}

// --- 5. Client Code ---
$orderService = new OrderService();

// The services subscribe to the events
$orderService->attach(new EmailService());
$orderService->attach(new InventoryService());

// The OrderService executes, and the Observers react automatically!
$orderService->placeOrder("MacBook Pro");
// Output:
// OrderService: Order placed for MacBook Pro.
// EmailService: Sending receipt for MacBook Pro to customer.
// InventoryService: Deducting stock for MacBook Pro.
?>

8. Best Practices #

• Push vs. Pull:

• *Push Model:* The Publisher sends the exact data payload to the update($data) method (as seen above). Best for simple data.

• *Pull Model:* The Publisher just calls update(), and passes *itself* (update($this)). The Observer then uses getters to pull the specific data it wants. Best for complex state changes.

9. Common Mistakes #

• The Memory Leak (Lapsed Listener Problem): If an Observer subscribes to a Subject that lives forever (like a global UI manager), but the Observer object is destroyed, the Subject's internal array still holds a memory reference to the dead Observer. This prevents the Garbage Collector from cleaning it up, causing massive memory leaks. *The Fix:* Always explicitly detach() or use Weak References.

10. Mini Project: Build a Stock Ticker #

1. 1. Subject: Create a StockTicker class with an attach() method and a setPrice($price) method that triggers notify().

1. 2. Observers: Create a MobileAppDashboard and a WallStreetTerminal that both implement StockObserver.

1. 3. Action: Attach both observers. Call setPrice(150.00). Both dashboards should independently print out the new price simultaneously.

11. Practice Exercises #

1. 1. Define the relationship between the "Subject" and the "Observer." How does this pattern effectively decouple the core business logic from ancillary services?

1. 2. Explain the "Lapsed Listener Problem." Why is it critical to explicitly unsubscribe (detach) observers in long-running applications?

12. MCQs with Answers #

13. Interview Questions #

• Q: Compare and contrast the "Push" model versus the "Pull" model in the Observer pattern. What are the bandwidth and coupling trade-offs of each approach?

• Q: A monolithic application is experiencing massive latency because the Checkout function makes 10 sequential, synchronous method calls to different services. Explain how implementing the Observer pattern (an Event Bus) resolves this tightly coupled bottleneck.

• Q: Walk me through the exact structural mechanics of the Model-View-Controller (MVC) architecture. Which of the GoF design patterns is utilized to ensure the View updates automatically when the Model's data changes?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #