Behavioral Patterns - Mediator Pattern Exercise

behavioral-patterns-mediator-pattern-exercise

The Mediator Pattern defines an object that encapsulates how a set of objects interact. In this exercise, we will create a mediator that helps us handle the cross-cutting business logic in the Command Pattern Exercise.

Reading Materials

  1. https://en.wikipedia.org/wiki/Mediator_pattern (15 minutes reading)

Practice Materials

  1. Extend the Command Pattern exercise by applying the Mediator Pattern to a new SignAllCommand class, which delegate the request to a mediator that does the actual business logic.

If you haven’t done the Command Pattern Exercise but you are already familiar with the Command Pattern, you can go straight to this exercise.

Components:

  1. Command (The common interface that has the execute and undo methods) or Colleague - Command
  2. ConcreteCommand (The actual command that implements the Command interface, and takes a receiver and calls its member methods.) - SignAllCommand and WriteCommand
  3. Client (The entry class that creates the command and its receiver) - App
  4. Receiver (The class that will be used in a command) - Document
  5. Invoker (The class that invokes a command) - DocumentRunner
  6. Stack (The object that keeps track of most recent executed commands. To undo, the stack just pops the last commands and executes its undo method.) - FixedStack
  7. Mediator (The component where all cross-cutting logic happens) - Mediator

Tip

  • Without using a mediator in this exercise, the SignAllCommand will have to hold the state of all the documents passed in. As the DocumentWriter application grows, more commands are introduced to the application, among which there may be similar group commands similar to the SignAllCommand that will have to hold other references of all the documents, which add unnecessary duplicated references across all group commands. A mediator could be a hub that holds the references to all documents and related operations. There could be more discussions on how to submodularize the mediator so that it doesn’t grow into a super long class with all different kind of tasks.

Solution

Extended Operation Manager Example – A Document Writer

Questions to discuss

  1. What are the common use cases to apply a Mediator Pattern?
  2. How do we submodularize a mediator so that it doesn’t grow into a class has too many responsibilities?

Comments

Popular posts from this blog

Distributed Transaction Management with REST and Try Confirm/Cancel Pattern

Creating a Library Project for Spring Boot

Exception Handling in WebMethods