A Behavior Object Pattern The Mediator Pattern A Behavior Object Pattern

Battling Class Complexity Consider an air traffic controller Many planes circle an airport If they communicated with each other the skies above an airport would be a chaos Accepted solution: have the planes communicate directly with an air traffic controller tower for permission to land The planes do not even have to know about each other This information is kept with the tower

Battling Class Complexity Let’s abstract this to classes and their objects in a program When class objects are allowed to communicate directly with each other then they become too tightly coupled When one object wishes to send a message to another then we need the equivalent of an air traffic controller to forward the message to the recipient Keep the dispatching information inside the new controller Call this coordinating object a mediator

AirController Airplane +mediator Boeing 747 Yerevan Int’l Cessna

Remarks Airplane is an abstract class for the concrete planes that fly AirController is an interface to concrete mediators Cessna and Boeing747 are the objects controlled by the mediator, called colleagues Yerevan International is the concrete mediator that coordinates the colleague objects

Most Importantly The Colleagues do not send messages to each other They send messages to the mediator The mediator sends messages to the recipient Each plane knows about the concrete controller Whenever something is to be communicated it goes to the AirController

The Mediator Pattern Mediator Colleague Concrete Coll 2 Concrete Med

Object View (run-time) aConcreteMediator aColleague aColleague mediator mediator aColleague aColleague mediator mediator

Mediator Encapsulates interconnects between objects Is the communications hub Is responsible for coordinating and conrolling colleague interaction Promotes loose coupling between classes By preventing from referring to each other explicitly Arbitrates the message traffic

How to Use Mediator Identify a collection of interacting objects whose interaction needs simplification Get a new abstract class that encapsulates that interaction Create a instance of that class and redo the interaction with that class alone But, don’t play God!

When to Use Mediator When a set of objects communicates in a well-defined, but complex way When reusing an object is difficult because it refers to and communicates with many other objects (tight coupling) When a behavior that is distributed between several classes should be customizable without a lot of subclassing

Related Patterns Observer--communication distributed by using observer and subject objects Mediator encapsulates the communication Facade--Create a class interface for an entire subsystem The subsystem doesn’t know about the Facade Facade doesn’t add functionality, Mediator does Mediator’s colleagues are aware of Mediator

The Facade Pattern Purpose: Create a class that is the interface to an entire subsystem whose diverse methods should remain within the system Consequences Hide the implementation of the subsystem from clients Promote weak coupling between the subsystem and the clients Does not prevent clients from using subsystem classes--should it?

Facade Pattern client client Facade Subsystem

Project Use Add a GUI to POST Decouple the GUI from the business logic Make the business logic totally unaware of the graphical interface--make it get called by the mediator, never directly from the GUI component

Example Business Logic Mediator GUI Payment Panel MakePayment() payment = new... makePayment() Complete this diagram for all GUI components!