SDSU CS 635: Advanced Object-Oriented Design & Programming
Spring Semester, 1998
Facade and Mediator

To Lecture Notes Index
© 1998, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 23-Apr-98

Contents of Doc 26, Facade and Mediator

CS 635 Doc 26 Facade & Mediator
References slide # 1
Facade slide # 2
...Review Wirfs-Brock CRC Design Process slide # 2
......Exploratory Phase slide # 3
......Analysis Phase slide # 4
......Subsystems slide # 5
...The Facade Pattern - Basic Idea slide # 6
...Consequences of Facade Pattern slide # 6
Mediator slide # 7
...Structure slide # 7
...Participants slide # 8
...Motivating Example slide # 9
...When to use the Mediator Pattern slide # 10
...Issues slide # 11

References


Designing Object-Oriented Software,Wirfs-Brock

Design Patterns: Elements of Resuable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, Addison Wesley, 1995, pp 185-194
Doc 26, Facade and Mediator Slide # 2

Facade

Review of Wirfs-Brock (CRC Design Process)


Who is on the team?

What are their tasks, responsibilities?

Who works with whom?


Who's related to whom?

Finding sub teams

Putting it all together

Doc 26, Facade and Mediator Slide # 3

Exploratory Phase


What are the goals of the system?

What must the system accomplish?

What objects are required to model the system and accomplish the goals?


What does each object have to know in order to accomplish each goal it is involved with?

What steps toward accomplishing each goal is it responsible for?


With whom will each object collaborate in order to accomplish each of its responsibilities?

What is the nature of the objects' collaboration


Doc 26, Facade and Mediator Slide # 4

Analysis Phase


Determine which classes are related via inheritance

Finding abstract classes

Determine class contracts


Divide responsibilities into subsystems

Designing interfaces of subsystems and classes


Construct protocols for each class

Produce a design specification for each class and subsystem

Write a design specification for each contract


Doc 26, Facade and Mediator Slide # 5

Subsystems


Subsystems are groups of classes, or groups of classes and other subsystems, that collaborate among themselves to support a set of contracts

There is no conceptual difference between the responsibilities of a class and a subsystem of classes

The difference between a class and subsystem of classes is a matter of scale

A subsystem should be a good abstraction

There should be as little communication between different subsystems as possible



Doc 26, Facade and Mediator Slide # 6

The Facade Pattern - Basic Idea


Create a class that is the interface to the subsystem

Clients interface with the Facade class to deal with the subsystem



Consequences of Facade Pattern


It hides the implementation of the subsystem from clients

It promotes weak coupling between the subsystems and its clients

It does not prevent clients from using subsystems class, should it?


Doc 26, Facade and Mediator Slide # 7

Mediator


A mediator is responsible for controlling and coordinating the interactions of a group of objects (not data structures)

Structure

Classes


Objects




Doc 26, Facade and Mediator Slide # 8

Participants


Mediator

Defines an interface for communicating with Colleague objects

ConcreteMediator

Implements cooperative behavior by coordinating Colleague objects

Knows and maintains its colleagues

Colleague classes

Each Colleague class knows its Mediator object

Each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague


Doc 26, Facade and Mediator Slide # 9

Motivating Example

Dialog Boxes

Objects



Interaction


How does this differ from a God Class?
Doc 26, Facade and Mediator Slide # 10

When to use the Mediator Pattern


When a set of objects communicate in a well-defined but complex ways

When reusing an object is difficult because it refers to and communicates with many other objects

When a behavior that's distributed between several classes should be customizable without a lot of subclassing


Doc 26, Facade and Mediator Slide # 11

Issues

How do Colleagues and Mediators Communicate?

1) Explicit methods in Mediator

class DialogDirector
     {
     private Button ok;
     private Button cancel;
     private ListBox courses;
     
     public void ListBoxItemSelected() { blah}
     
     public void ListBoxScrolled() { blah }     
     etc.
     }

2) Generic change method

class DialogDirector {
     private Button ok;
     private Button cancel;
     private ListBox courses;
     
     public void widgetChanged( Object changedWidget) { 
          if ( changedWidget == ok )               blah
          else if (  changedWidget == cancel )     more blah
          else if (  changedWidget == courses )     even more blah
     }
}


Doc 26, Facade and Mediator Slide # 12
3) Generic change method overloaded

class DialogDirector
     {
     private Button ok;
     private Button cancel;
     private ListBox courses;
     
     public void widgetChanged( Button changedWidget)
          { 
          if ( changedWidget == ok )
               blah
          else if (  changedWidget == cancel )
               more blah
          }

     public void widgetChanged( ListBox changedWidget)
          { 
          now find out how it changed and 
          respond properly          
          }
     }


Doc 26, Facade and Mediator Slide # 13
Differences from Facade

Facade does not add any functionality, Mediator does

Subsystem components are not aware of Facade

Mediator's colleagues are aware of Mediator and interact with it

© 1998, All Rights Reserved, SDSU & Roger Whitney

visitors since 23-Apr-98