Design Patterns
Section 7.1 (JIA’s)Section 7.2.1 (till page 259) (JIA’s)
Section 7.2.2(JIA’s)Section 10.4.1 (JIA’s)
Design Patterns Pattern is a term used to describe architectural
designs
Recurring Problems in architectural designs (Christopher Alexander, 1977) describe solutions for those problems
A pattern is a generic or reusable solution to a recurring problem
Can that be applied to software?
Design Patterns Similarities between software and architecture
Both are based on creative processes Design must satisfy customer’s needs Design my be feasible to engineer Designers must balance many competing constraints
and requirements
As a result, software design patterns are descriptions (templates) of solutions to recurring problems in software design Not a finished design!
Design Patterns Why use design patterns?
Why reinvent the wheel? Use (reuse) common solutions for common problems
Boost confidence in software systems --use established design patterns that have been proven effective
Provide a common vocabulary for software designers to communicate about software design
Work started by Gamma et al. Design Patterns [Gamma et al., 1995]
Design Patterns 23 general-purpose design patterns [Gamma et al.]
Creational patterns Deal with the process of object creation E.g. Singleton --- One instance of class can exist
Structural patterns Deal with the static composition and structure of classes and
objects E.g. Adapter --- Convert an interface of a class to a different
one expected by other classes Behavioral patterns
Deal with dynamic interaction among classes and objects E.g. Template --- Separate variant and invariant behaviors
among related classes
Design Patterns Pattern name (Also known as) Problem addressed
Detailed description When to apply (list of preconditions)
The Solution Class diagram that depicts the participants of
the pattern and the relationships among them A list of classes participating in the pattern
Does not describe a concrete solution, is a template instead
Describe results and tradeoffs
Singleton Design Pattern Pattern name: Singleton Category: Creational design pattern Intent: Ensure that a class has only one instance and provides a
global point of access to it Also known as: N/A Applicability: Use the Singleton pattern when there must be
exactly one instance of a class and it must be accessible to clients from a well-known access point
a GUI application must have a single mouse an active modem needs one and only one telephone line an operating system can only have one window manager or, a PC is connected to a single keyboard Such objects are accessed by disparate objects throughout a
software system, and therefore require a global point of access
Structure: NEXT SLIDE Participants: Itself
Singleton’s Structure
Singleton Declares the unique instance of the class as a static variable Defines a static method getInstance() for clients to access the
unique instance --- global access point Code
public class Singleton { private static Singleton theOnlyOne = null;
//usually has other instance variables as well
private Singleton() { }
public static Singleton getInstance() { // global access point
if(theOnlyOne == null) { theOnlyOne = new Singleton(); } return theOnlyOne; }}
Singleton public class SingletonInstantiator { public SingletonInstantiator() {
Singleton instance = Singleton.getInstance();
Singleton anotherInstance = new Singleton(); !!! }
} Test if working properly?
Example Singletonpublic class SingleRandom {
private Random gen; private static SingleRandom theOnlyOne = new
SingleRandom();
private SingleRandom() {gen = new Random(); } public void setSeed(int seed)
{ gen.setSeed(seed); } public int nextInt() { return gen.nextInt(); } public static SingleRandom getInstance() {
return theOnlyOne; }
Template Design Pattern One of the most widely used design patterns
Useful for separating the variant and the invariant object behavior
Invariant means common to all subclasses The invariant behavior is placed in the abstract class
(template) Concrete methods common to all subclasses Abstract class contains abstract methods for the variant behavior
Any subclasses that inherit it can override the abstract methods and implement the specifics needed in that context
In the body of TemplateMethod() --- invariant --- there are calls to operation1() and operation2() …
operation1() and operation2() are abstract defined by the subclasses which override them
Template Design Pattern Why abstract classes for templates?
Contain behavior that is common to all its subclasses encapsulated in non-abstract methods
Might even be defined as final
The abstract methods in such a class require that context-specific behavior be implemented for each concrete subclass
Called Hook methods
Template Design Pattern A program that sorts data using different sorting
algorithms: The AbstractClass would have a method called Sort()
-- the invariant behavior Sort uses the abstract methods in the class, which are specified by
any class that inherits from it
The hook methods in this case might be compare() (compares two objects and returns the one that is
"higher") sortPass() (performs one iteration of a particular sorting
algorithm)
The usual control structure of object calls and relations is reversed!
It is the parent class that calls the method in the subclass
Template Design Pattern Pattern Name: Template Method Category: Behavioral design pattern Intent: To define the skeleton of an algorithm deferring
some steps to subclasses, thus allowing the subclasses to redefine certain steps of the algorithm This way, subclasses can override parts of the
algorithm without changing its overall structure Applicability: The Template Method Pattern should be used
to implement the invariant parts of an algorithm once and leave it to the subclasses to implement variant behavior
localize the common behavior among subclasses to avoid code duplication
Structure of the Template Design Pattern
##
Template Design Pattern Participants:
Generic (or Abstract) Class Defines the abstract hook methods (variant behavior)
that concrete classes override to implement the steps of an algorithm
Implements a template method (invariant behavior) that defines the skeleton of an algorithm called by the hook methods
Concrete Class Implements the hook methods to carry-out subclass-
specific steps of the algorithm defined in the template method
Example 7.3 page 267 www.users.csbsju.edu/~jschnepf/CS230/Code/Plotter/index.html
Adapter Design Pattern Pattern Name: Adapter Category: Structural design pattern Intent: To convert the contract of a class into another contract that new clients expect
The Adapter pattern is used so that two incompatible interfaces can work together
The join between them is called an Adapter We convert interface of one class into interface expected by the
client A.K.A: Wrapper Applicability: when we need to use an existing class with a “different” interface than provided
Structure of Object Adapter Pattern
<< >>
Structure of Object Adapter Pattern
Object adapters use delegation to adapt one interface to another
The adapter implements the target interface that the client expects to see, while it holds an instance of the adaptee
Can extend adaptee instead (limited to a single adaptee) Object (composition) vs. Class (inheritance) Adapter
When the client calls the request() method on its target object (the adapter), the request is translated into the corresponding specific request on the adaptee
Adapters enable the client and the adaptee to be completely decoupled from each other
Only the adapter knows about both of them
Structure of Class Adapter Pattern
Adaptee<< >>
Adapter Design Pattern Participants
Client Requires objects conforming to ATarget
ATarget interface Defines the interface expected by the Client
Adaptee class Defines the “undesired” interface of an existing
class Adapter
Adapts the interface of Adaptee to ATarget via delegation (composition) or inhertince
Example Object Adapter CLIENT application would like to use a stack interface on DList
(i.e. adapt ADAPTEE to TARGET) ADAPTEE /* DoubleLinkedList */ class DList {
public void insert (int pos, Object o) { ... } public void remove (int pos, Object o) { ... } public void insertHead (Object o) { ... } public void insertTail (Object o) { ... } public Object removeHead () { ... } public Object removeTail () { ... } public Object getHead () { ... } public Object getTail () { ... } }
TARGET interface Stack {
void push (Object); Object pop (); Object peek(); }
Example Object Adapter
ADAPTER /* Adapt DList class to Stack interface */ class DListStack implements Stack {
private DList _dlist;
public DListStack() {_dlist = new DList(); }
public void push (Object o) { _dlist.insertHead (o); }
public Object pop () {return _dlist.removeHead ();}
public Object peek() {return _dlist.getHead ();} }
Example Class Adaptor /* Adapt DList class to Stack interface */ ADAPTER class DListImpStack extends DList implements Stack {
public void push (Object o) {insertHead (o); } public Object pop () {return removeHead (); } public Object peek() {return getHead(); }
}
Example (Object Adapter) Example page 514-530 Table (Generic display table)
Client Expects entries of type TableEntry
ListTableModel
TableEntry (row in a table) Target
Student (Information on a Student) Adaptee Does not conform to TableEntry
StudentEntry2 Adapter Adapts Student to TableEntry
Example
Table Table.ListTableModelStudent
StudentEntry
11
1 0..*
«interface»TableEntry
1
1
Example (Class Adapter) Table (Generic display table)
Client Expects entries of type TableEntry
TableEntry (row in a table) Target
Student (Information on a Student) Adaptee Does not conform to TableEntry
StudentEntry Adapter Adapts Student to TableEntry
Example
Table Table.ListTableModelStudent
StudentEntry
11
1 0..*
«extends»
«interface»TableEntry
Top Related