cs 501 introduction to design patterns nate nystrom eric melin november 9, 1999
Post on 18-Dec-2015
214 views
TRANSCRIPT
CS 501Introduction to Design Patterns
Nate Nystrom
Eric Melin
November 9, 1999
Motivation
• Designing reusable software is hard– usually impossible to get right the first time– takes several uses of a design to get it right
• Experts base new designs on prior experience
• In many systems, you find recurring patterns of software components– classes, protocols, etc.
Design patterns
• Idea: extract these common patterns and create a catalog of design patterns– allows other designers to reuse successful
designs and avoid unsuccessful ones– creates a common vocabulary for
discussing designs– 1995: Design Patterns book by the Gang of
Four (Gamma, Helm, Johnson, Vlissides)»describes 21 common patterns
What is a design pattern?
• A pattern has four components:– A name– A problem– A solution– Consequences
Name
• Immediately allows you to design at a higher level of abstraction
• Allows you to discuss the pattern with others
Problem
• What problem does the pattern solve?
• When do you apply the pattern?
Solution
• Elements that make up the design• Relationships, responsibilities,
collaborations• NOT a particular concrete design or
implementation– A pattern is a template that can be
applied in many different situations
Consequences
• Results and trade-offs of applying the pattern
• Impact on system's flexibility, extensibility, portability
What is not a design pattern?
• A design of a data structure• A domain-specific design• A design of an entire application• A design used only once
– A design pattern should capture mature, proven practices
Classifying design patterns
• GoF identified two criteria for classifying design patterns– Purpose– Scope
Purpose
• Creational patterns– describe how objects are created
• Structural patterns– describe the composition of classes or
objects
• Behavioral patterns– describe the interaction of classes or
objects and how responsibility is distributed
Scope
• Class patterns– Deal with relationships between classes
and their subclasses
• Object patterns– Deal with relationships between objects– Relationships can change at run-time
and are thus more dynamic
Non-OO design patterns
• Design patterns are not limited to object-oriented software
• Objects are just one way to partition a system, sometimes not the best way
• You will find many more mature patterns in legacy systems than you will in OO software
Before Patterns: Motorola
• Factors preventing software reuse– Strong coupling of classes/objects– Short-term needs superseded longer-term
• Architecture specifications suffered from– Ambiguity and lack of precision in the specs– Differing terminology– No direct access to the architects
Review of OO concepts
• OO programs are made up of objects– An object packages both data and
operations on that data– An object's operations are called
methods– An object's implementation is defined by
its class– New classes can be defined using
existing classes through inheritance
Encapsulation
• In pure OO: method invocations (messages) are the only way an object can execute an operation– The object's internal state is
encapsulated– Encapsulation is often violated for
efficiency
Polymorphism
• Different objects can handle identical messages with different implementations
• Dynamic binding: Run-time association of a message to an object and one of the object's operations
• Can substitute objects that implement the same interface at run-time
Inheritance
• There is a distinction between an object's class and its type– Class defines how an object is implemented– Type defines the object's interface– Java thus defines two forms of inheritance
» Implementation inheritance– Ex: class B extends A { m() {} }
» Interface inheritance– Ex: class C implements I { m() {} }
Reuse through subclassing
• Easier to modify the implementation being reused
• But, breaks encapsulation» Implementation of the subclass bound to
that of the parent– any change to the parent requires change to the
subclass
»Must reimplement parent if any aspect of the its implementation is not appropriate to the new context in which it is used
Reuse through composition (1)
• Requires carefully designed interfaces• Doesn’t break encapsulation
– Any object can be replaced by another at run-time if it implements the same interface
– Fewer implementation dependencies
• Helps design– keeping each class encapsulated forces
you to keep classes simple
Reuse through composition (2)
• But, composition leads to more objects in the system– Behavior depends on interrelationships
between many objects not on one class
GoF’s Principles of OO design
• Program to an interface, not an implementation
• Favor composition over inheritance» Ideally, get all the functionality you need by
composing existing components» In practice, available components aren’t rich
enough»Reuse by inheritance easier to create new
components that can be composed of old ones
Summary
• Patterns– are a good team communication medium– are extracted from working designs– capture the essential parts of a design in
compact form– can be used to record and encourage the
reuse of "best practices"– are not necessarily object-oriented
The Iterator pattern
• Provides a way to access elements of an aggregate object without exposing the underlying representation– Ex: a List class
»Want to traverse the list in several ways– forward– backward– filtered– sorted– ...
Motivation for iterators
• Don't want to bloat the List interface with several different traversals
»Even if you do, you can't anticipate all the possible traversals
• Might want >1 traversal on the same list
• Iterator moves responsibility for access and traversal from the aggregate to an iterator object
Iterator example (1)
class List {size() {}add() {}remove() {}
}
interface ListIterator {getFirst();getNext();
}
Iterator example (2)class FilteredListIterator implements ListIterator {
List.Node curr;FilteredListIterator(List list, Filter f) {}
getFirst() {curr = list.head;while (curr != null) {
if (f.accepts(curr.data))break;
curr = curr.next;}return curr;
}
getNext() {}}
More on the Iterator pattern
• Iterators provide a common interface for accessing aggregates– Can use the same interface for lists
implemented as arrays and lists implements as linked lists
– Easier to change data structure implementations
• See java.util in JDK 1.2 for good examples
The Visitor pattern
• Represent an operation to be performed on the elements of an object structure
• Lets you defined a new operation withoutchanging the classes of the elements on which it operates
Visitor example: a compiler
• Consider a compiler that represents a program as an abstract syntax tree
• Need to perform operations on the AST– type checking– optimization– code generation
Example AST
V a r i In t 0
A ss ign
O p (< ) V a r i V a r n
C o m p a re
V a r i
In c rem e nt
V a r t
V a r f
V a r i
B o o l true n il
A rg L ist
A rg L ist
C a ll
A ss ign
V a r a V a r i
A rra yR e f V a r t
A ss ign n il
L is t
L is t
F o rLo op
for (i = 0; i < 100; i++) {t = f(i,true);a[i] = t;
}
Design 1
• Operations treat nodes of different types differently– Ex: code generated for assignments is
different than code generated for calls
• Proposed design: add a method to each node class to perform a particular operation on that node type
Design 1 example
class Assign {
genCode() {}
typeCheck() {}
optimize() {}
}
class Call {
genCode() {}
typeCheck() {}
optimize() {}
}
Problem with Design 1
• Every time we add or modify an operation, we have to change the class for each node type– Ex: one Java bytecode analyzer has 61
different node types
Design 2
• Better solution:– Put each operation in a different class
called a visitor– Works well if we assume adding new
node types is uncommon»We have to update all the visitors when a
new node type is added
Design 2 example (1)interface ASTVisitor {
visitAssign(Assign a);visitCall(Call c);...
}
class Assign{
Exp left;Exp right;...accept(ASTVisitor v) {
left.accept(v);right.accept(v);v.visitAssign(this);
}}
Design 2 example (2)
class TypeCheckVisitor implements ASTVisitor{
visitAssign(Assign a){
Type ltype = a.getLeft().getType();Type rtype = a.getRight().getType();if (! Ltype.isSuperOf(rtype)) {
errors.add(...);}
}...
}
Creational and Structural Patterns
• Creational – Encapsulate knowledge about which concrete
classes the system uses– Hide how instances of these classes are
created and put together– Examples: Singleton, Abstract Factory
• Structural– Describe how classes and objects are
composed into larger structures– Examples: Proxy, Façade, Composite
Singleton
• Motivation– Some classes need exactly one instance
» One window manager, one file system, one print spooler– Need global access, but global variable does not prevent multiple
instantiation– Have class keep track of it’s sole instance
Intent – Ensure a class has only one instance and provide a global point of access
Singleton (2)
• Applicability– There must be exactly one instance of a class and it must be
accessible to multiple clients– The sole instance should be extensible by subclassing, and
clients should be able to use subclass without modifying code
• Consequences– Controlled access to sole instance– Reduced name space (over global variable)– Extendable implementation– Permits a variable number of instances – (easy to change if
don’t want singleton)– More flexible than static member functions – allows subclassing
and easy to change to multiple number of instances
Abstract Factory
Intent – Provide an interface for creating families of related objects without specifying their concrete classes
Example of Abstract Product and Concrete Products
Abstract Factory (2)
Abstract Factory (3)
• Applicability– A system should be independent of how its
products are created, composed, and represented
– A system should be configured with multiple families of products
– Need to enforce constraint “a family of related product objects should be glued together”
– Want to provide library of products and reveal only their interfaces
Abstract Factory (4)
• Consequences – Concrete classes are isolated to concrete
factory– Allows easy exchanging of product families– Promotes consistency amongst products– It is hard to add new types of products
ProxyA proxy provides a placeholder for another object to access it
Proxy (2)• Structure
– The proxy has the same interface or superclass as the real subject
– The proxy contains a reference to real subject which the proxy can use to forward requests to the real subject
• Applicability– A remote proxy acts as a local representation for a remote
object– A virtual proxy creates expensive objects on demand
» Example – a proxy for a graphical image when image is not on screen
– A protection proxy controls access to the original object– A firewall proxy protects local clients from outside world– A cache proxy (server proxy) saves network resources by
storing results – Smart Reference
» Example - garbage collector reference counter (Smart Pointers)
Proxy (3)
• Consequences– Proxy introduces a level of indirection.– Remote proxy can hide fact that object resides
elsewhere– Copy-on-write is possible – this is a significant
optimization for heavy-weight components
Façade
Intent - provide a unified interface to a set of interfaces in a subsystem
Façade (2)
• Motivation – Structuring a system into subsystems reduces complexity– Want to reduce communications and dependencies
between subsystems
• Applicability– Want to provide a simple interface to a complex subsystem– There are many dependencies between clients and
implementation classes in a subsystem. Want to decouple the subsystem from clients and other subsystems
– Want to layer subsystems – Can use a façade to define entry point to each subsystem level
Façade (3)
• Consequences– Façade reduces the number of objects that clients
deal with to make the subsystem easier to use– Promotes weak coupling between subsystem and
clients. This allows you to change subsystem implementation without affecting clients
– Allows clients to use subsystem classes if they need to
– Subsystem components are not aware of façade
Comparison of Patterns
• Proxy vs. Façade – A facade represents a system of objects – A proxy represents a single object – A facade simplifies the interact between
client and the system – A proxy controls the access to the single
object
CompositeCompose objects into tree structures to let clients treat individual objects and compositions of objects uniformly
Composite (2)
Composite (3)
• Motivation – How does a window hold and deal with the different
items it has to manage?– Graphics - Containers and widgets
» Panel, Menu, Window» Line, Rectangle, Text
– Cut And Paste
Composite (4)
• Applicability – Want to represent part-whole hierarchies of objects– Want clients to be able to ignore the difference between
compositions of objects and individual objects.
• Consequences– Whenever client code expects a primitive object, it can
also receive a composite object– Makes the client simple– Facilitates adding of new components– Can make design overly general – makes it hard to
restrict the components of a composite
Composite Implementation Issues• Explicit parent references• Sharing parents – wasteful not to, but need ability for
child to have multiple parents• Maximize Component interface – Component should
define as many common operations as possible• Child management operations are tricky
– Can define child management operations in Component Class (root of hierarchy)
» Unsafe - What does adding a child to a leaf node mean?
– Can define child management in Composite class » Safety, but – Now downcasts or instanceof checks into
components and leaves are necessary
References
• Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, Addison Wesley, 1995, pp 207-217
• http://www.eli.sdsu.edu/courses/spring98/cs635/index.html • http://st-www.cs.uiuc.edu/cgi-bin/wikic/wikic• http://www.tcm.hut.fi/~pnr/GoF-models/html/