Mediator vs Observer Patterns: Key Differences and Implementations

4.2.3 Differences Between Mediator and Observer Patterns

In the realm of software design patterns, the Mediator and Observer patterns are often discussed together due to their roles in managing communication and dependencies between objects. However, they serve distinct purposes and are suited to different scenarios. Understanding these differences is crucial for software engineers aiming to implement effective and maintainable code architectures.

Understanding the Mediator Pattern

The Mediator Pattern is a behavioral design pattern that centralizes complex communications and control between related objects. It acts as a hub for communication, ensuring that objects are only aware of the mediator and not of each other. This pattern is particularly useful in scenarios where multiple objects interact in complex ways, and it helps reduce the many-to-many relationships to one-to-many relationships with the mediator.

Key Characteristics of the Mediator Pattern

• Centralized Communication: The mediator acts as an intermediary, managing the interactions between different components.
• Decoupling: Components interact with the mediator instead of directly with each other, leading to a reduction in dependencies.
• Simplified Object Relationships: By centralizing communication, the mediator reduces the complexity of object relationships.

Implementing the Mediator Pattern in JavaScript

Let’s consider a simple chat application where users can send messages to each other. The mediator pattern can be used to manage the communication between users.

class ChatRoom {
  showMessage(user, message) {
    const time = new Date().toLocaleTimeString();
    console.log(`${time} [${user.getName()}]: ${message}`);
  }
}

class User {
  constructor(name, chatRoom) {
    this.name = name;
    this.chatRoom = chatRoom;
  }

  getName() {
    return this.name;
  }

  sendMessage(message) {
    this.chatRoom.showMessage(this, message);
  }
}

// Usage
const chatRoom = new ChatRoom();
const user1 = new User('Alice', chatRoom);
const user2 = new User('Bob', chatRoom);

user1.sendMessage('Hello Bob!');
user2.sendMessage('Hi Alice!');

In this example, the ChatRoom acts as the mediator, managing the communication between User objects. Users do not communicate directly with each other but through the ChatRoom.

Understanding the Observer Pattern

The Observer Pattern is another behavioral design pattern, which defines a one-to-many dependency between objects. It allows multiple observer objects to listen to and react to events or changes in the state of a subject object. This pattern is particularly useful for implementing distributed event-handling systems.

Key Characteristics of the Observer Pattern

• One-to-Many Dependency: A subject can have multiple observers that are notified of changes.
• Loose Coupling: Subjects do not need to know who their observers are, promoting a decoupled architecture.
• Dynamic Relationships: Observers can be added or removed at runtime, providing flexibility.

Implementing the Observer Pattern in JavaScript

Consider a scenario where a stock price changes, and multiple systems need to be notified of this change.

class Stock {
  constructor(symbol, price) {
    this.symbol = symbol;
    this.price = price;
    this.observers = [];
  }

  addObserver(observer) {
    this.observers.push(observer);
  }

  removeObserver(observer) {
    this.observers = this.observers.filter(obs => obs !== observer);
  }

  notifyObservers() {
    this.observers.forEach(observer => observer.update(this));
  }

  setPrice(newPrice) {
    this.price = newPrice;
    this.notifyObservers();
  }
}

class StockObserver {
  constructor(name) {
    this.name = name;
  }

  update(stock) {
    console.log(`${this.name} notified of ${stock.symbol} price change to ${stock.price}`);
  }
}

// Usage
const googleStock = new Stock('GOOGL', 1500);
const observer1 = new StockObserver('Observer 1');
const observer2 = new StockObserver('Observer 2');

googleStock.addObserver(observer1);
googleStock.addObserver(observer2);

googleStock.setPrice(1520);

In this example, the Stock class acts as the subject, and StockObserver instances are the observers. When the stock price changes, all registered observers are notified.

Comparing Mediator and Observer Patterns

While both patterns deal with communication and dependencies, they do so in different ways and are suited to different use cases.

Centralization vs. Decentralization

• Mediator Pattern: Centralizes the communication logic in a single mediator object. This is beneficial when you need to manage complex interactions between multiple objects, as it simplifies the communication paths and reduces dependencies.

• Observer Pattern: Decentralizes the communication by allowing subjects to notify multiple observers directly. This is useful when you need to broadcast changes to multiple objects without the subject needing to know the details of the observers.

Use Cases

• Mediator Pattern: Ideal for scenarios where multiple objects need to collaborate and communicate in a controlled manner. Examples include UI components interacting with each other, or managing workflows in a system.

• Observer Pattern: Suited for event-driven architectures where changes in one object need to be propagated to multiple dependent objects. Commonly used in implementing event listeners, data binding in UI frameworks, and real-time notifications.

Code Complexity

• Mediator Pattern: Can lead to a more complex mediator class as it grows to handle more interactions. However, it simplifies the individual components by offloading the communication logic to the mediator.

• Observer Pattern: Keeps the subject and observer classes simple, but the relationships can become complex if there are many observers or if the notification logic is intricate.

Diagrammatic Comparison

The following diagram illustrates the structural differences between the Mediator and Observer patterns:

    graph LR
	  subgraph Mediator Pattern
	    ComponentA --> Mediator
	    ComponentB --> Mediator
	    Mediator --> ComponentA
	    Mediator --> ComponentB
	  end
	  subgraph Observer Pattern
	    Subject --> Observer1
	    Subject --> Observer2
	  end

Best Practices and Common Pitfalls

Best Practices

• Mediator Pattern: Keep the mediator class focused and avoid letting it become a “God object” that knows too much about the components it manages. Use it to manage interactions, not to hold business logic.

• Observer Pattern: Ensure that observers are efficiently managed, especially in terms of adding and removing them. Avoid memory leaks by ensuring observers are properly deregistered when no longer needed.

Common Pitfalls

• Mediator Pattern: Over-reliance on the mediator can lead to a single point of failure. Ensure that the mediator is robust and well-tested.

• Observer Pattern: The potential for a large number of observers can lead to performance issues if not managed properly. Consider using techniques like throttling or debouncing for frequent updates.

Conclusion

Both the Mediator and Observer patterns are powerful tools in a developer’s toolkit, each serving distinct purposes. The Mediator pattern is ideal for managing complex interactions and dependencies between objects, while the Observer pattern excels in scenarios requiring event-driven updates and loose coupling. By understanding their differences and appropriate use cases, developers can design more efficient and maintainable systems.

Quiz Time!