SDSU CS 635 Advanced Object-Oriented Design & Programming
Spring Semester, 2001
Flyweight & Facade
Previous    Lecture Notes Index    Next    
© 2001, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 03-May-01

Contents of Doc 21, Flyweight & Facade


Design Patterns: Elements of Reusable Object-Oriented Software , Gamma, Helm, Johnson, Vlissides, Addison-Wesley, 1995, pp. 185-206

The Design Patterns Smalltalk Companion, Alpert, Brown, Woolf, 1998, pp. 179-212

Doc 21, Flyweight & Facade Slide # 2



When a program needs a large number of objects, the space requirements can be come too large

The example in the text uses objects to represent individual characters of the alphabet

Using objects allows the program to treat characters like any other part of the document - as an object

A character, like “G”, may require a fair amount of information:

Most of this information is the same for all instances of the same letter

Doc 21, Flyweight & Facade Slide # 3
Intrinsic State

Extrinsic State

So create one instance of the object and use the same object wherever you need an instance

The one object can store the intrinsic state, but someone else needs to store the extrinsic state for each context of the object

Doc 21, Flyweight & Facade Slide # 4


Doc 21, Flyweight & Facade Slide # 5


The pattern can be used when all the following are true

      MyClass* objectPtrA;
      MyClass* objectPtrB;
      if ( objectPtrA == objectPtrB ) //testing object identity

Extrinsic state is data that is stored outside the object

The extrinsic state is passed to the object as an argument in each method

Doc 21, Flyweight & Facade Slide # 6


State transitions

Start State comes first
When get user name transfer to HaveUserName State
When get correct password transfer to Authorized State

HaveUserName and Authorized states need the user name

In concurrent server we may have many (100's) different users connected at the same time.

State creation can become expensive, so create each state once

Each time use the state pass the user name to the state

Doc 21, Flyweight & Facade Slide # 7
class HaveUserName extends SPopState
   private HaveUserName() {};
   private static HaveUserName instance;
   public getInstance( )
      if ( instance == null ) 
         instance = new HaveUserName();
      return instance;
   public SPopState pass( String userName, String password )
      if ( validateUser( userName, password )
         return Authorized.getInstance();
         return Start.getInstance();

Doc 21, Flyweight & Facade Slide # 8


Separating state from the flyweight

This is the hard part

Must remove the extrinsic state from the object

Store the extrinsic state elsewhere

This needs to take up less space for the pattern to work

Each time you use the flyweight you must give it the proper extrinsic state

Managing Flyweights

Cannot use object identity on flyweights

Need factory to create flyweights, cannot create directly

How do we know when we are done with a flyweight?

Doc 21, Flyweight & Facade Slide # 9


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 21, Flyweight & Facade Slide # 10
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 21, Flyweight & Facade Slide # 11
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 21, Flyweight & Facade Slide # 12

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 21, Flyweight & Facade Slide # 13
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 subsystem classes directly, should it?

Facade does not add new functionality to the subsystem

Copyright ©, All rights reserved.
2001 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 03-May-01    Next