Transcript Design Pattern Examples

Frameworks and Design Patterns
Reusability Revisited
ceg860 (Prasad)
L156DP
1
• A toolkit is a library of reusable classes designed
to provide useful, general-purpose functionality.
• E.g., Java APIs (awt,
util, io, net,
etc)
• An application framework is a specific set of
classes that cooperate closely with each other and
together embody a reusable design for a category
of problems.
• E.g., Java APIs (Applet,
• E.g., MFC, JFC, etc.
Thread,
etc)
• A design pattern describes a general recurring
problem in different domains, a solution, when to
apply the solution, and its consequences.
ceg860 (Prasad)
L156DP
2
A framework embodies a complete design
of an application, while a pattern is an
outline of a solution to a class of problems.
A framework dictates the architecture of
an application and can be customized to get
an application. (E.g., Java Applets)
When one uses a framework, one reuses the
main body of the framework and writes the
code it calls.
When one uses a toolkit, one writes the
main body of the application that calls the
code in the toolkit. (E.g., Java AWT)
ceg860 (Prasad)
L156DP
3
Why catalog/learn design patterns?
• Provides (an application-independent)
vocabulary to communicate, document, and
explore design alternatives.
• Captures the experience of an expert
(especially the rationale behind a design and
the trade-offs involved) and codifies it in a
form that is potentially “reusable”.
• What, why, how, …
Example is not another way to teach, it is the
only way to teach. -- Albert Einstein
» (Cf. Vince Lombardi Quote)
ceg860 (Prasad)
L156DP
4
Example : The Intermediary Pattern
• A client interacts with an intermediary while
the requested services are really carried out
by the server/worker.
Proxy
• Intermediary acts like a transmission agent.
• E.g., rpc, rmi implementations.
Client
ceg860 (Prasad)
Proxy
L156DP
Server
5
Translator/Adapter
• Intermediary acts like a translator between the client
and the server.
• E.g., Format/protocol conversions.
Client
ceg860 (Prasad)
Adapter
L156DP
Server
6
Facade
• Intermediary acts like a focal point distributing work
to other agents.
• E.g., telnet, ftp, … --> web-browser.
• E.g., local/network files, devices, ... -> UNIX files
Server1
Client
Facade
Server2
Server3
ceg860 (Prasad)
L156DP
7
Bridge/Abstract Factory/Handle
• Intermediary defines the interface but not the
implementation.
• E.g., Motif/Mac/Windows look and feel.
• E.g., java.io.InputStream, java.io.OutputStream.
Impl1
Client
Bridge
Impl2
Impl3
ceg860 (Prasad)
L156DP
8
Example : The Traversal Pattern
• Task - Visit every element in an aggregate
structure in a well-defined order and
perform an action on each element.
Iterator
• Defines a mechanism for enumerating elements of
an aggregate without exposing the representation
(by supporting first(), next(), item(),
isDone(),
etc.)
• E.g., (pre-, in-) post-order traversals of tree.
(Cf. Higher-order functions in Scheme.)
ceg860 (Prasad)
L156DP
9
Model/View/Controller (Smalltalk)
• Pattern for graphical interactive system
 Model
: Application Object
 View
: Screen Presentation
 Controller : User interaction
MVC pattern decouples these three
different categories of objects to increase
flexibility and reuse. This facilitates support
for multiple views of the same information
and multiple ways of interaction.
ceg860 (Prasad)
L156DP
10
Java Support for MVC
• The multiple views and the model communicate
through a subscribe/notify protocol.
– Java 1.1 Delegation-based Event Model
– java.beans classes
• PropertyChangeEvent, PropertyChangeListener,
PropertyChangeSupport, etc.
• Controller specifies the way a view responds to
user input.
– Java AWT classes
– Buttons, Pulldown menus, Pop-up menus, Keyboard
shortcuts, etc.
ceg860 (Prasad)
L156DP
11
Multi-Panel Interactive Systems
Functional Decomposition vs
Object-Oriented Decomposition
ceg860 (Prasad)
L156DP
12
Multi-Panel System : Pattern
• Session:
Example
 sequence of states
• In each state:
 display panel seeking
user input / new request
 read user input/query
checking for consistency
 process user request
 update database
 transition to next state
ceg860 (Prasad)
L156DP
– Airline Reservation
– States
User Identification
Enquiry on flights
(for certain time)
Display flights
Enquiry on seats
Reserve seat
Help, Exit, ...
13
Encoding FSM using go to
Benquire_flights :
display_panel(“Enquire_flights”);
do {
read_input(Input, okay);
} while (!okay);
Process(Input, Next);
switch (Next) {...
case 1: go to Bexit;
case 2: go to Bhelp;
case 3: go to Benquiry_on_seats;
...}
 Each block encodes a state. “Spaghetti” code.
 One module : Unsuitable to maintain and reuse.
ceg860 (Prasad)
L156DP
14
Functional Top-Down Solution
• Introduce transition function to localize gotos.
• Turn each state into a module (routine).
execute_session
init
display
ceg860 (Prasad)
transition
execute_state
read_input
L156DP
final
process
15
void execute_session() {
int state, next;
state = initial;
do {
execute_state(state,next);
state = transition(state,next);
} while (! is_final(state));
}
void execute_state(int state,int next) {
T input;
int next;
display(state);
read_input(state);
process(state,next);
}
ceg860 (Prasad)
L156DP
16
Limitations of functional decomposition
• The various modules (routines: display,
read_input, process) are tightly coupled via
the input argument (state).
• Thus, each module (routine) has information about
all possible variants (states).
• Remedy (Inversion)
Instead of building modules around operations
and distributing data structures between the
resulting routines, use the data types as a basis
for modularization, attaching each routine to
the corresponding data structure.
ceg860 (Prasad)
L156DP
17
Law of Inversion Illustrated
(Functional vs Object-Oriented Decomposition)
Data Structure
Data 1
Data 2
Date Type
Data 1
Proc 1
Data 3
Data 2
Routine
Proc 1
Proc 2
Proc 3
ceg860 (Prasad)
Proc 2
Data 3
Proc 3
L156DP
18
Object-Oriented Architecture
abstract class State {
int next;
T input;
abstract void display();
abstract void read_input();
abstract void process();
void execute(next) {
display();
read_input();
process();
}}
ceg860 (Prasad)
L156DP
19
class Application {
State[][] transition; State[] associated_state;
Application(int n, int m) {
transition
= new State[n][m];
associated_state = new State[n];
}
void put_state(State s, int i){…}
void put_transition(State src, State dst,
int choice){…}
int initial;
void choose_initial(int i){…}
void execute {
State s;
int stn = initial;
while ( !stn ) {
s = associated_state(stn);
s.execute();
stn = transition(stn,s.next)
}}}
ceg860 (Prasad)
L156DP
20
Building an Interactive Application
Application airline_reservation = new
new Application(num_states, num_choices);
...
airline_reservation.put_state(s,i)
...
airline_reservation.put_transition(s,d,c)
...
airline_reservation.choose_initial(i)
airline_reservation.execute_session()
...
• Class Application
is reusable in building other
multi-panel interactive applications.
ceg860 (Prasad)
L156DP
21
Undo-Redo Facility
(using history)
Inheritance, Dynamic Binding,
Polymorphism
ceg860 (Prasad)
L156DP
22
Requirements
• Applicable to wide class of interactive
applications.
• Incremental w.r.t. command additions.
• Use “reasonable” amount of storage.
• Support arbitrary-level of undoing.

Practical Issues:
 Part of the User Interface.
 Some commands undoable.
ceg860 (Prasad)
L156DP
23
abstract class Command {
abstract void execute();
abstract void undo();
void redo() {
execute();
}
}
• Commands can be undone/redone.
• undo and redo are operations that cannot
be undone/redone.
• Each subclass of class Command adds
application specific details.
ceg860 (Prasad)
L156DP
24
A History List
isItem()
item()
...
isFirst()
count
...
prev
next
isLast()
cursor
! isLast()
ceg860 (Prasad)
L156DP
25
List History = new List();
Read_decode_request;
if (request instanceOf Command) {
if (! History.isLast())
History.removeAllItemsToRight();
History.addItem(request);
request.execute();
} else if (requested instanceOf Undo)
if (History.isItem()) {
History.item.undo();
History.prev;
} else ;// nothing to undo
else if (requested instanceOf Redo)
if (! History.isLast()) {
History.next;
History.item.redo();
} else ; // nothing to redo
ceg860 (Prasad)
L156DP
26
Reusability and Extendibility
• class Command
can be subclassed to
incorporate new commands.
• class Command can be modified to
incorporate additional functionality such as
adding help documentation, monitoring
statistics, etc, for each command.
• This pattern can be used in an entirely new
application, to support undo/redo capability.
ceg860 (Prasad)
L156DP
27