Patterns Again - PowerPoint PPT Presentation

About This Presentation
Title:

Patterns Again

Description:

Describes situations appropriate for using the pattern ... Proxy pattern ... Such a menu can easily be implemented with the Command Pattern ... – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 50
Provided by: bernd183
Learn more at: http://www.cs.fsu.edu
Category:

less

Transcript and Presenter's Notes

Title: Patterns Again


1
Patterns Again
  • Review of design pattern concepts
  • What is a design pattern?
  • Modifiable designs
  • Patterns already discussed
  • Adaptor Wrapper for existing code
  • Bridge Facilitating alternate implementations
  • Composite Representing recursive hierarchies
  • More patterns
  • Abstract Factory Provide manufacturer
    independence
  • Builder Hide a complex creation process
  • Proxy Provide Location transparency
  • Command Encapsulate control flow
  • Observer Provide publisher/subscribe mechanism
  • Strategy Support family of algorithms, separate
    of policy and mechanism

2
Design Patterns - Definition
  • Name
  • Uniquely identifies pattern
  • Evokes details to designer
  • Problem description
  • Describes situations appropriate for using the
    pattern
  • Usually includes modifiability, extensibility,
    and nonfunctional design goals
  • Solution
  • State as a set of collaborating entities (mostly
    classes and objects)
  • Typically includes an illustration
  • Consequences
  • Describe the trade-offs and alternatives with
    respect to the design goals being addressed

3
Design Pattern Commentary
  • A design pattern is ...
  • a template solution to a recurring design
    problem
  • Look before re-inventing the wheel just one more
    time
  • reusable design knowledge
  • Higher level than classes or data structures
  • Lower level than application frameworks
  • an example of modifiable design
  • Learning to design begins with studying other
    designs

4
Why are modifiable designs important?
  • A modifiable design enables
  • an iterative and incremental development cycle
  • concurrent development
  • risk management
  • flexibility to change
  • to minimize the introduction of new problems
    when fixing old ones
  • to deliver more functionality after initial
    delivery

5
What makes a design modifiable?
  • Low coupling and high cohesion
  • Clear dependencies
  • Explicit assumptions
  • How do design patterns help?
  • They are generalized from existing systems
  • They provide a shared vocabulary to designers
  • They provide examples of modifiable designs
  • Abstract classes
  • Delegation

6
On to More Patterns!
  • Structural pattern
  • Adapter
  • Bridge
  • Composite
  • Facade
  • Proxy
  • Behavioral pattern
  • Command
  • Observer
  • Strategy
  • Creational Patterns
  • Abstract Factory
  • Builder
  • Singleton

7
Adaptor A.2
adaptee
8
Adaptor Example
  • C stdstack (or fsuCStack)
  • Uses vector (existing code) to define stack
    interface
  • http//www.cs.fsu.edu/lacher/courses/COP4530/lect
    ures/adts/slide19.html
  • Note inheritance is conceptual, but not
    necessarily realized by inheritance in the
    specific language!

9
Bridge A.3
(wikipedia)
10
Bridge Example
  • (text fig. 8-7)

imp
11
Comparing Adaptor and Bridge
  • Using Inheritance and Delegation
  • Adaptor inherits interface then delegates
    implementation
  • Bridge delegates abstract implementation then
    derives specific implementations
  • Can derive from either construct
  • Adaptor
  • Assumes existing (legacy) code
  • Adapted code may be old and ugly or modern and
    useful
  • Either way, you are not intending to change the
    existing code
  • Bridge
  • Assumes you have not yet implemented the
    interface
  • Facilitates different implementation choices

12
Composite A.5

Component
move()
resize()
Checkbox
Button
Composite
Label
Window
Panel
Applet
13
Figure 8-14, Anatomy of a preference dialog.
Aggregates, called Panels, are used for grouping
user interface objects that need to be resized
and moved together.
14
Figure 8-15, UML object diagram for the user
interface objects of Figure 8-14.
prefsWindow
topPanel
mainPanel
buttonsPanel
okButton
titleLabel
c1Checkbox
c2Checkbox
cancelButton
c3Checkbox
c4Checkbox
15
Façade A.6
Encapsulate complex systems
16
Proxy Pattern
  • What is expensive?
  • Object Creation
  • Object Initialization
  • Defer object creation and object initialization
    to the time you need the object
  • Proxy pattern
  • Reduces the cost of accessing objects
  • Uses another object (the proxy) that acts as a
    stand-in for the real object
  • The proxy creates the real object only if the
    user asks for it (and is entitled to it)

17
Proxy pattern
  • Interface inheritance is used to specify the
    interface shared by Proxy and RealSubject.
  • Delegation is used to catch and forward any
    accesses to the RealSubject (if desired)
  • Proxy patterns can be used for lazy evaluation
    and for remote invocation.
  • Proxy patterns can be implemented with a Java
    interface.

18
Proxy Applicability
  • Remote Proxy
  • Local representative for an object in a different
    address space
  • Caching of information Good if information does
    not change too often
  • Virtual Proxy
  • Object is too expensive to create or too
    expensive to download
  • Proxy is a standin
  • Protection Proxy
  • Proxy provides access control to the real object
  • Useful when different objects should have
    different access and viewing rights for the same
    document.
  • Example Grade information for a student shared
    by administrators, teachers and students.

19
Virtual Proxy example
realSubject
  • Images are stored and loaded separately from text
  • If a RealImage is not loaded a ProxyImage
    displays a grey rectangle in place of the image
  • The client cannot tell that it is dealing with a
    ProxyImage instead of a RealImage
  • A proxy pattern can be easily combined with a
    Bridge

20
Before
21
Controlling Access
22
After
23
Towards a Pattern Taxonomy
  • Structural Patterns
  • Adapters, Bridges, Facades, and Proxies are
    variations on a single theme
  • They reduce the coupling between two or more
    classes
  • They introduce an abstract class to enable future
    extensions
  • They encapsulate complex structures
  • Behavioral Patterns
  • Here we are concerned with algorithms and the
    assignment of responsibilies between objects Who
    does what?
  • Behavorial patterns allow us to characterize
    complex control flows that are difficult to
    follow at runtime.
  • Creational Patterns
  • Here we our goal is to provide a simple
    abstraction for a complex instantiation process.
  • We want to make the system independent from the
    way its objects are created, composed and
    represented.

24
Patterns
  • Structural patterns
  • Adapter
  • Bridge
  • Composite
  • Facade
  • Proxy
  • Behavioral pattern
  • Command
  • Observer
  • Strategy
  • Creational Patterns
  • Abstract Factory
  • Builder
  • Singleton

25
Command Pattern Motivation
  • You want to build a user interface
  • You want to provide menus
  • You want to make the user interface reusable
    across many applications
  • You cannot hardcode the meanings of the menus for
    the various applications
  • The applications only know what has to be done
    when a menu is selected.
  • Such a menu can easily be implemented with the
    Command Pattern

26
Command pattern
Invoker
Command execute()
Client
binds
  • Client creates a ConcreteCommand and binds it
    with a Receiver.
  • Client hands the ConcreteCommand over to the
    Invoker which stores it.
  • The Invoker has the responsibility to do the
    command (execute or undo).

27
Command pattern Applicability
  • Encapsulate a request as an object, thereby
    letting you
  • parameterize clients with different requests,
  • queue or log requests, and
  • support undoable operations
  • Uses
  • Undo queues
  • Database transaction buffering

28
Observer pattern
  • Define a one-to-many dependency between objects
    so that when one object changes state, all its
    dependents are notified and updated
    automatically.
  • Also called Publish and Subscribe
  • Uses
  • Maintaining consistency across redundant state
  • Optimizing batch changes to maintain consistency

29
Observer pattern (continued)
Subject
Observers
9DesignPatterns2.ppt
30
Observer pattern (contd)

observers
subject
  • The Subject represents the actual state, the
    Observers represent different views of the state.
  • Observer can be implemented as a Java interface.
  • Subject is a super class (needs to store the
    observers vector) not an interface.

31
Sequence diagram for scenario Change filename
to foo
aListView
anInfoView
aFile
getState()
foo
32
Animated Sequence diagram
33
Observer pattern implementation in Java
  • // import java.util
  • public class Observable extends Object
  • public void addObserver(Observer o)
  • public void deleteObserver(Observer o)
  • public boolean hasChanged()
  • public void notifyObservers()
  • public void notifyObservers(Object arg)
  • public abstract interface Observer
  • public abstract void update(Observable o, Object
    arg)
  • public class Subject extends Observable
  • public void setState(String filename)
  • public string getState()

34
Strategy Pattern
  • Many different algorithms exists for the same
    task
  • Examples
  • Breaking a stream of text into lines
  • Parsing a set of tokens into an abstract syntax
    tree
  • Sorting a list of customers
  • The different algorithms will be appropriate at
    different times
  • Rapid prototyping vs delivery of final product
  • We dont want to support all the algorithms if we
    dont need them
  • If we need a new algorithm, we want to add it
    easily without disturbing the application using
    the algorithm

35
Strategy Pattern
Policy
Context ContextInterface()

ConcreteStrategyC AlgorithmInterface()
ConcreteStrategyB AlgorithmInterface()
ConcreteStrategyA AlgorithmInterface()
Policy decides which Strategy is best given the
current Context
36
Applying a Strategy Pattern in a Database
Application
Database Search() Sort()

Strategy
37
Applicability of Strategy Pattern
  • Many related classes differ only in their
    behavior. Strategy allows to configure a single
    class with one of many behaviors
  • Different variants of an algorithm are needed
    that trade-off space against time. All these
    variants can be implemented as a class hierarchy
    of algorithms

38
Patterns
  • Structural patterns
  • Adapter
  • Bridge
  • Composite
  • Facade
  • Proxy
  • Behavioral pattern
  • Command
  • Observer
  • Strategy
  • Creational Patterns
  • Abstract Factory
  • Builder
  • Singleton

39
Abstract Factory Motivation
  • 2 Examples
  • Consider a user interface toolkit that supports
    multiple looks and feel standards such as Motif,
    Windows 95 or the finder in MacOS.
  • How can you write a single user interface and
    make it portable across the different look and
    feel standards for these window managers?
  • Consider a facility management system for an
    intelligent house that supports different control
    systems such as Siemens Instabus, Johnson
    Controls Metasys or Zumtobes proprietary
    standard.
  • How can you write a single control system that is
    independent from the manufacturer?

40
Abstract Factory
AbstractProductA
AbstractFactory CreateProductA CreateProductB
Client
ProductA1
ProductA2
AbstractProductB
CreateProductA CreateProductB
ConcreteFactory1
ProductB1
ProductB2
CreateProductA CreateProductB
ConcreteFactory2
Initiation Assocation Class ConcreteFactory2
initiates the associated classes ProductB2 and
ProductA2
41
Applicability for Abstract Factory Pattern
  • Independence from Initialization or
    Represenation
  • The system should be independent of how its
    products are created, composed or represented
  • Manufacturer Independence
  • A system should be configured with one family of
    products, where one has a choice from many
    different families.
  • You want to provide a class library for a
    customer (facility management library), but you
    dont want to reveal what particular product you
    are using.
  • Constraints on related products
  • A family of related products is designed to be
    used together and you need to enforce this
    constraint
  • Cope with upcoming change
  • You use one particular product family, but you
    expect that the underlying technology is changing
    very soon, and new products will appear on the
    market.

42
Example A Facility Management System for the
Intelligent Workplace
LightBulb
IntelligentWorkplace InitLightSystem InitBlindSys
tem InitACSystem
Facility Mgt System
InstabusLight Controller
ZumbobelLight Controller
Blinds
InitLightSystem InitBlindSystem InitACSystem
SiemensFactory
InstabusBlind Controller
ZumtobelBlind Controller
InitLightSystem InitBlindsystem InitACSystem
ZumtobelFactory
43
Builder Pattern Motivation
  • Conversion of documents
  • Software companies make their money by
    introducing new formats, forcing users to
    upgrades
  • But you dont want to upgrade your software every
    time there is an update of the format for Word
    documents
  • Idea A reader for RTF format
  • Convert RTF to many text formats (EMACS,
    Framemaker 4.0, Framemaker 5.0, Framemaker 5.5,
    HTML, SGML, WordPerfect 3.5, WordPerfect 7.0,
    .)
  • Problem The number of conversions is open-ended.
  • Solution
  • Configure the RTF Reader with a builder object
    that specializes in conversions to any known
    format and can easily be extended to deal with
    any new format appearing on the market

44
Builder Pattern
BuildPart()
Construct()
Builder
Director
For all objects in Structure
Builder-gtBuildPart()
Represen- tation B
BuildPart() GetResult()
ConcreteBuilderB
BuildPart() GetResult()
ConcreteBuilderA
Represen- tation A
45
Example
Parse()
RTFReader
ConvertCharacter() ConvertFontChange ConvertPara
graph()
TextConverter
While (t GetNextToken()) Switch t.Type
CHAR builder-gtConvertCharacter(t.Char) FONT
bulder-gtConvertFont(t.Font) PARA
builder-gtConvertParagraph
ConvertCharacter() ConvertFontChange ConvertPar
agraph() GetASCIIText()
AsciiConverter
ConvertCharacter() ConvertFontChange ConvertPar
agraph() GetASCIIText()
HTMLConverter
ConvertCharacter() ConvertFontChange ConvertPar
agraph() GetASCIIText()
TexConverter
HTMLText
AsciiText
TeXText
46
When do you use the Builder Pattern?
  • The creation of a complex product must be
    independent of the particular parts that make up
    the product
  • In particular, the creation process should not
    know about the assembly process (how the parts
    are put together to make up the product)
  • The creation process must allow different
    representations for the object that is
    constructed. Examples
  • A house with one floor, 3 rooms, 2 hallways, 1
    garage and three doors.
  • A skyscraper with 50 floors, 15 offices and 5
    hallways on each floor. The office layout varies
    for each floor.

47
Comparison Abstract Factory vs Builder
  • Abstract Factory
  • Focuses on product family
  • The products can be simple (light bulb) or
    complex (engine)
  • Does not hide the creation process
  • The product is immediately returned
  • Builder
  • The underlying product needs to be constructed as
    part of the system, but the creation is very
    complex
  • The construction of the complex product changes
    from time to time
  • The builder pattern hides the creation process
    from the user
  • The product is returned after creation as a final
    step
  • Abstract Factory and Builder work well together
    for a family of multiple complex products

48
Summary
  • Structural Patterns
  • Focus How objects are composed to form larger
    structures
  • Problems solved
  • Realize new functionality from old
    functionality,
  • Provide flexibility and extensibility
  • Behavioral Patterns
  • Focus Algorithms and the assignment of
    responsibilities to objects
  • Problem solved
  • Too tight coupling to a particular algorithm
  • Creational Patterns
  • Focus Creation of complex objects
  • Problems solved
  • Hide how complex objects are created and put
    together

49
Conclusion
  • Design patterns
  • Provide solutions to common problems.
  • Lead to extensible models and code.
  • Can be used as is or as examples of interface
    inheritance and delegation.
  • Apply the same principles to structure and to
    behavior.
  • Design patterns solve all your software
    engineering problems
  • Poll What are your top 3 favorites?
Write a Comment
User Comments (0)
About PowerShow.com