Design Patterns CSCI 6221 – Advanced Software Paradigms Fall 2014

Design Patterns

CSCI 6221 – Advanced Software ParadigmsFall 2014

Architectural Paradigms

> Readings— Kaisler: Sections 4

© Ray Renner - GWU

CSCI 6221 – Advanced Software Paradigms

2

Definitions

> A pattern is a recurring solution to a standard problem, in a context.

> Christopher Alexander, a professor of architecture…— A Pattern Language: Towns, Buildings, Construction (1977)— A Timeless Way of Building (1979)

> “A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

> “Each pattern is a three-part rule which expresses a relation between a certain context, a problem, and a solution.”

© Ray Renner - GWU 3


Patterns in Architecture

© Ray Renner - GWU


4

Definitions

> Jim Coplein— Organizational Patterns of Agile Software Development (2004)— “I like to relate this definition to dress patterns…”— “... I could tell you how to make a dress by specifying the route of

a scissors through a piece of cloth in terms of angles and lengths of cut. Or, I could give you a pattern. Reading the specification, you would have no idea what was being built or if you had built the right thing when you were finished. The pattern foreshadows the product: it is the rule for making the thing, but it is also, in many respects, the thing itself.”




6

Patterns in Engineering

> When experts need to solve a problem, they seldom invent a totally new solution. More often they will recall a similar problem they have solved previously and reuse the essential aspects of the old solution to solve the new problem. They tend to think in problem-solution pairs

> How do other engineers find and use patterns?— Mature engineering disciplines have handbooks

describing successful solutions to known problems— Automobile designers don't design cars from scratch

using the laws of physics– Instead, they reuse standard designs with successful

track records, learning from experience

> Developing software from scratch is also expensive — Patterns support reuse of software architecture and design

© Ray Renner - GWU

Pattern Oriented Software Engineering

> Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad— Pattern Oriented Software Construction (1996)

> "A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate."

© Ray Renner - GWU


7

Categories of Patterns

> Patterns can be grouped into three categories according to their level of abstraction— Architectural Patterns or Styles

– SOA, Client-Server, etc.

— Design Patterns– Abstracts reoccurring class and/or object design structures

— Idioms– Low-level pattern specific to a programming language

© Ray Renner - GWU


8

Pattern Characteristics

> A pattern describes a solution to a recurring problem that arises in specific design situations.

> Patterns are not invented; they are distilled from practical experience.

> Patterns describe a group of components (e.g., classes or objects), how the components interact, and the responsibilities of each component. That is, they are higher-level abstractions than classes or objects.

> Patterns provide a vocabulary for communication among designers. The choice of a name for a pattern is very important.

© Ray Renner - GWU


9

Pattern Characteristics

> Patterns help document the architectural vision of a design. If the vision is clearly understood, it will less likely be violated when the system is modified.

> Patterns provide a conceptual skeleton for a solution to a design problem and, hence, encourage the construction of software with well-defined properties

> Patterns are building blocks for the construction of more complex designs.

> Patterns help designers manage the complexity of the software. When a recurring pattern is identified, the corresponding general solution can be implemented productively to provide a reliable software system

© Ray Renner - GWU


10


11

The “Gang of Four” (GoF)

> Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides (Addison-Wesley, 1995)— Design Patterns book catalogs 23 different patterns as solutions

to different classes of problems, in C++ & Smalltalk— The problems and solutions are broadly applicable, used by

many people over many years— GOF presents each pattern in a structured format

– Essential Elements– Structured Descriptions

© Ray Renner - GWU

Essential Elements of Design Patterns (1/2)

> Pattern Name — A handle to describe a design problem, its solutions and

consequences — Allows for design at a higher level of abstraction — Communication mechanism for designers

> Problem — Describes when to apply the pattern — Explains the problem and its context — May include a list of conditions that must be met before it makes

sense to apply the pattern

© Ray Renner - GWU


12


> Solution — Describes the elements that make up the design, their

relationships, responsibilities and collaborations — It is not the design or implementation — A pattern is like a template — Provides an abstract description (UML-based) of a design

problem and how a general arrangement of elements solves it

> Consequences — Results and trade-offs of applying the pattern — Critical for evaluating design alternatives and understanding

costs and benefits of the pattern — The pattern's impact on the system's flexibility, extensibility or

portability may be considered

© Ray Renner - GWU


13

Describing Design Patterns (1/4)

> Pattern Name and Classification — Important because it becomes part of your design vocabulary.

> Intent — What does the design pattern do? — What is its rationale and intent? — What particular design issue or problem does it address?

> Also Known As — Other well-known names for the pattern, if any.

> Motivation — A scenario that illustrates a design problem and how the class

and object structures in the pattern solve the problem

© Ray Renner - GWU


14


> Applicability — When should the pattern be applied? — How can you recognize these situations?

> Structure — A graphical representation of the classes in the pattern using a

notation such as Object Modeling Technique (OMT) or UML to illustrate sequences of requests and collaborations.

> Participants — The classes and/or objects participating in the design pattern

and their responsibilities.

> Collaborations — How the participants collaborate to carry out their

responsibilities.

© Ray Renner - GWU


15


> Consequences — How does the pattern support its objectives? — What are the trade-offs and results of using the pattern? — What aspect of system structure does it let you vary

independently?

> Implementation— What pitfalls, hints, or techniques should you be aware of when

implementing the pattern? — Are there language-specific issues?

> Sample Code — Code fragments that illustrate how you might implement the

pattern in a particular object-oriented language.

© Ray Renner - GWU


16


17


> Known Uses — Examples of the pattern found in real systems.

> Related Patterns — What design patterns are closely related to this one? — What are the important differences? — With which other patterns should this one be used?

© Ray Renner - GWU

Classification of Design Patterns

By purpose and by scope

> Creational patterns

— Abstract the instantiation process— Make a system independent to its realization— Class Creational use inheritance to vary the instantiated classes— Object Creational delegate instantiation to an another object

© Ray Renner - GWU


18


19


> Structural patterns

— Class Structural patterns concern the aggregation of classes to form largest structures

— Object Structural pattern concern the aggregation of objects to form largest structures

© Ray Renner - GWU


20


> Behavioral patterns

— Concern with algorithms and assignment of responsibilities between objects

— Describe the patterns of communication between classes or objects

— Behavioral class pattern use inheritance to distribute behavior between classes

— Behavioral object pattern use object composition to distribute behavior between classes

© Ray Renner - GWU

Design Patterns (Gamma)

© Ray Renner - GWU


21

Creational Structural Behavioral

Factory Method Adapter Interpreter

Template Method

Abstract Factory Adapter Chain of Responsibility

Builder Bridge Command

Prototype Composite Iterator

Singleton Decorator Mediator

Façade Memento

Flyweight Observer

Proxy State

Strategy

Visitor

Class

Object

Purpose

Scope

Creational Patterns

> Abstract Factory:— Factory for building related objects

> Builder:— Factory for building complex objects incrementally

> Factory Method:— Method in a derived class creates associates

> Prototype:— Factory for cloning new instances from a prototype

> Singleton:— Factory for a singular (sole) instance



Structural Patterns

> Adapter:— Translator adapts a server interface for a client

> Bridge:— Abstraction for binding one of many implementations

> Composite:— Structure for building recursive aggregations

> Decorator:— Decorator extends an object transparently

> Facade:— Simplifies the interface for a subsystem

> Flyweight:— Many fine-grained objects shared efficiently.

> Proxy:— One object approximates another



Behavioral Patterns

> Chain of Responsibility:— Request delegated to the responsible service provider

> Command:— Request or Action is first-class object, hence re-storable

> Iterator:— Aggregate and access elements sequentially

> Interpreter:— Language interpreter for a small grammar

> Mediator:— Coordinates interactions between its associates

> Memento:— Snapshot captures and restores object states privately



Behavioral Patterns (cont.)

> Observer:— Dependents update automatically when subject changes

> State:— Object whose behavior depends on its state

> Strategy:— Abstraction for selecting one of many algorithms

> Template Method:— Algorithm with some steps supplied by a derived class

> Visitor:— Operations applied to elements of a heterogeneous object

structure



How To Use a Design Pattern?

> Read the pattern once through for an overview. — Pay special attention to the Applicability and Consequences

sections — Ensure the pattern is right for your problem

> Go back and study the Structure, Participants and Collaborations sections

> Look at the sample code. > Choose names for pattern participants that are

meaningful in the application context. > Define the classes. > Define application-specific names for operations in the

pattern. > Implement the operations to carry out the responsibilities

and collaborations in the pattern.© Ray Renner - GWU


26

Design Pattern Selection

> Consider how design patterns solve design problems. — Find appropriate objects — Determine object granularity — Specify object interfaces

> Scan Intent sections. > Study how patterns interrelate. > Study patterns of like purpose.

— Study similarities and differences

> Examine a cause of redesign. — Consider what might force a change to your design

> Consider what should be variable in your design. — Consider what you want to be able to change without redesign -

encapsulate the concept that varies

© Ray Renner - GWU


27

CSCI 6221 - Advanced Software Paradigms

28

Singleton Pattern

> Motivation— we need to have exactly only one instance for a class (ex.

Printer spooler)— Make the class itself responsible for keeping track of its sole

instance — The class provide a way to access the instance

> Applicability— There must be only one instance of a class accessible from a

well-known point

© Ray Renner - GWU


29

Singleton Pattern

> Structure

© Ray Renner - GWU

Singleton

Static Instance()SingletonOperation()GetSingletonData()

Static uniqueInstanceSingletonData

Return uniqueInstance


30

Singleton Pattern

> Participants— Singleton class

> Collaborations— Access only through Singleton’s instance operation

> Consequences— Controlled access to sole instance— Permits refinement of operation and representation— More flexible than class operations

© Ray Renner - GWU


31

Example of Singleton use

> We had to have only one instance for class Director. We simply solve our problem using Singleton Pattern

© Ray Renner - GWU

Director

Static Instance()Given(n_ticket:int):voidError():void

Static UniqueInstance


32

Decorator Pattern

> Motivation— Add responsibilities to individual object not to an entire class— conforming the interface of the component decorated

© Ray Renner - GWU


33

Decorator Pattern

> Structure

© Ray Renner - GWU

Component

Operation()

ConcreteComponent

Operation()

Decorator

Operation()

ConcreteDecoratorAOperation()AddedState

ConcreteDecoratorBOperation()Addedbehavior


34

Decorator Pattern

> Participants— Component

– Define the interface for objects that can have responsibilities added to them dynamically

— Concrete Component– Defines an object to which additional responsibilities can be

attached

— Decorator – Mantains a reference to a Component object and defines an

interface that conforms to Component’s interface

— ConcreteDecorator– Added responsibilities to the component

© Ray Renner - GWU


35

Decorator Pattern

> Consequences— More flexibility than static inheritance— Avoids feature-laden classes high up in the hierarchy— A decorator and its component are not identical— Lots of little objects

© Ray Renner - GWU


36

Example of Decorator

> Motivation— If you have a TextView object that displays text in a Window— TextView has no scroll bars by default— TextView has no border by default …

© Ray Renner - GWU


37


> Structure

© Ray Renner - GWU

aBorderDecorator

component

aScrollDecorator

component

aTextView


38


> Structure

© Ray Renner - GWU

VisualComponent

Draw()

TextView

Draw()

Decorator

Draw()

ScrollDecorator BorderDecorator

Draw()ScrollTo()

ScrollPosition

Draw()DrawBorder()

BorderWidth


Model-View-Controller Design Pattern

> Name (essence of the pattern)— Model View Controller (MVC)

> Context (where does this problem occur)— MVC is an architectural pattern that is used when developing

interactive application such as a shopping cart on the Internet.

> Problem (definition of the reoccurring difficulty)— User interfaces change often, especially on the internet where

look-and-feel is a competitive issue. Also, the same information is presented in different ways. The core business logic and data is stable.



MVC continued

> Solution (how do you solve the problem)— Use the software engineering principle of “separation of

concerns” to divide the application into three areas: — Model encapsulates the core data and functionality— View encapsulates the presentation of the data there can be

many views of the common data— Controller accepts input from the user and makes request from

the model for the data to produce a new view.


How did it come about?

> Presented by Trygve Reenskaug in 1979> First used in the Smalltalk-80 framework

— Used in making Apple interfaces (Lisa and Macintosh)



MVC Structure



Model Role

> The Model maintains the application state and contains the data, which includes:— Persistent information stored in databases— Current information related to active sessions— Has methods to access and update it’s data and state.— Often, it implements an interface which defines the allowed

model interactions. Implementing an interface enables models to be pulled out and replaced without code changes.

> Responsibilities include:— Applying rules / transactions to modify state— Notifies Views of change— Taking instructions from the Controller— Responds to state queries



View Role

> The View presents a user interface, including information and transactional controls— There can be multiple views displaying the model at any one

time.– For example, a companies finances over time could be

represented as a table and a graph.– These are just two different views of the same data.

— When the Model is updated, all Views are informed and given a chance to update themselves.

> Responsibilities include:— Present required information to user— Request data from Model as needed (to create displays for the

user)— Sends User Gestures to Controller— Allows the Controller to select the appropriate View



Controller Role

> The Controller handles user actions— Users interact with the controller.— It interprets mouse movement, clicks, keystrokes, etc— Communicates those activities to the model – eg: delete row,

insert row— It’s interaction with the model indirectly causes the View(s) to

update

> Responsibilities include: — Maps user actions to Model updates and/or View changes— Validate user requests (correctness, completeness)— Invoke Model components to handle requested transactions— Set the appropriate View perspective



MVC Component Responsibilities

> View: Present the user interface

> Model: Maintain the application state

> Controller: Handle user actions



MVC Implementation with Observer Pattern

> Individual Views implement the Observer interface and register with the model.

> The model tracks the list of all observers that subscribe to changes.

> When a model changes, the model iterates through all registered observers and notifies them of the change.

© Ray Renner - GWU


47

MVC Example

a b ca

bcViews

Controller

Modela b c

503020

a = 50%b = 30%c = 20%

See

Interact




49

What Makes it a Pattern?

> A Pattern must:— Solve a problem and be useful— Have a context and can describe where the solution can be

used— Recur in relevant situations— Provide sufficient understanding to tailor the solution— Have a name and be referenced consistently

© Ray Renner - GWU


50

When to Use Patterns

> Solutions to problems that recur with variations— No need for reuse if problem only arises in one context

> Solutions that require several steps:— Not all problems need all steps— Patterns can be overkill if solution is a simple linear set of

instructions

> Solutions where the solver is more interested in the existence of the solution than its complete derivation— Patterns leave out too much to be useful to someone who really

wants to understand— They can be a temporary bridge

© Ray Renner - GWU


51

Benefits of Design Patterns

> Design patterns enable medium-scale reuse of software architectures and also help document systems

> Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available

> Patterns help improve developer communication> Pattern names form a common vocabulary

© Ray Renner - GWU


52

Drawbacks to Design Patterns

> Patterns do not lead to direct code reuse> Patterns are deceptively simple> Teams may suffer from pattern overload> Patterns are validated by experience and discussion

rather than by automated testing> Integrating patterns into a software development

process is a human-intensive activity.

© Ray Renner - GWU


53

Suggestions for Effective Use

> Do not recast everything as a pattern— Instead, develop strategic domain patterns and reuse existing

tactical patterns

> Institutionalize rewards for developing patterns> Directly involve pattern authors with application

developers and domain experts> Clearly document when patterns apply and do not apply> Manage expectations carefully.

© Ray Renner - GWU

Enterprise Design Patterns

> Design patterns vs. enterprise design patterns— both operate on a more abstract level than single

objects and their relations— design patterns focus on (optionally) single-threaded

local applications— enterprise design patterns comprise additional,

enterprise-related factors: distribution, transactions, performance, scalability

© Ray Renner - GWU


54

Publish and Subscribe

© Ray Renner - GWU


55

From Enterprise Integration Patternshttp://www.eaipatterns.com/eaipatterns.html

Publish and Subscribe

> Problem: How can the sender broadcast an event to all interested receivers?

> Solution: Send the event on a Publish-Subscribe Channel, which delivers a copy of a particular event to each receiver.

> Details: — A Publish-Subscribe Channel works like this: It has one input channel

that splits into multiple output channels, one for each subscriber. — When an event is published into the channel, the Publish-Subscribe

Channel delivers a copy of the message to each of the output channels.

— Each output channel has only one subscriber, which is only allowed to consume a message once. In this way, each subscriber only gets the message once and consumed copies disappear from their channels.

© Ray Renner - GWU


56

Intercepting Filter

Context Incoming requests need to be processed prior to handling Requests require different processing

Problem Controller require standardized requests Requests and responses must be processed before and after handling

Forces Centralized, yet modular method of pre- and post-processing is needed De-coupling of processing and dispatching Ease of extension

Bartosz Walter<[email protected]>


57

Intercepting Filter: solution

Solution Use a Intercepting Filter to centralize pre- and post-processing

of requests outside of the controller Filters make a Responsibility Chain (GoF)


58

Intercepting Filter: structure


59

Intercepting Filter: interactions


60

Idioms

> Definition: "An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language." [Buschmann]

> An idiom is a low-level abstraction. It is usually a language-specific pattern that deals with some aspects of both design and implementation.

© Ray Renner - GWU


61

Idiom Example: Java Iterator

ArrayList<String> alist = new ArrayList<String>(); // . . . Add Strings to alist

for (Iterator<String> it = alist.iterator(); it.hasNext(); ) { String s = it.next(); // No downcasting required. System.out.println(s); }

© Ray Renner - GWU


62

Design Patterns and Frameworks

> Design patterns are more abstract than frameworks> Design patterns are smaller architectural elements than

frameworks> Design patterns are less specialized than frameworks> Framework is executable software, design pattern

represent knowledge about software> Frameworks are the physical realization of one or more

software pattern solutions,pattern are instructions for how to implement those solutions

© Ray Renner - GWU


63

Resources

> http://www.dofactory.com/Default.aspx> http://hillside.net/patterns/> http://

www.javaworld.com/columns/jw-java-design-patterns-index.html

> http://martinfowler.com/eaaCatalog/> http://www.eaipatterns.com/eaipatterns.html

© Ray Renner - GWU


64

http://www.dofactory.com/Default.aspx

http://hillside.net/patterns/

http://www.javaworld.com/columns/jw-java-design-patterns-index.html






Class Exercise

> Fill Out A Design Pattern for a Re-Occurring Problem.

© Ray Renner - GWU


65


> Pattern Name > Problem

— Describes when to apply the pattern — Explains the problem and its context — May include a list of conditions that must be met before it makes

sense to apply the pattern

© Ray Renner - GWU


66


> Solution — Describes the elements that make up the design, their

relationships, responsibilities and collaborations — It is not the design or implementation — A pattern is like a template — Provides an abstract description (UML-based) of a design

problem and how a general arrangement of elements solves it

> Consequences — Results and trade-offs of applying the pattern — Critical for evaluating design alternatives and understanding

costs and benefits of the pattern — The pattern's impact on the system's flexibility, extensibility or

portability may be considered

© Ray Renner - GWU


67


> Pattern Name and Classification — Important because it becomes part of your design vocabulary.

> Intent — What does the design pattern do? — What is its rationale and intent? — What particular design issue or problem does it address?

> Also Known As — Other well-known names for the pattern, if any.

> Motivation — A scenario that illustrates a design problem and how the class

and object structures in the pattern solve the problem

© Ray Renner - GWU


68


> Applicability — When should the pattern be applied? — How can you recognize these situations?

> Structure — A graphical representation of the classes in the pattern using a

notation such as Object Modeling Technique (OMT) or UML to illustrate sequences of requests and collaborations.

> Participants — The classes and/or objects participating in the design pattern

and their responsibilities.

> Collaborations — How the participants collaborate to carry out their

responsibilities.

© Ray Renner - GWU


69


> Consequences — How does the pattern support its objectives? — What are the trade-offs and results of using the pattern? — What aspect of system structure does it let you vary

independently?

> Implementation— What pitfalls, hints, or techniques should you be aware of when

implementing the pattern? — Are there language-specific issues?

> Sample Code — Code fragments that illustrate how you might implement the

pattern in a particular object-oriented language.

© Ray Renner - GWU


70


71


> Known Uses — Examples of the pattern found in real systems.

> Related Patterns — What design patterns are closely related to this one? — What are the important differences? — With which other patterns should this one be used?

© Ray Renner - GWU

License

© Ray Renner - GWU


Attribution-ShareAlike 3.0 UnportedYou are free:

to Share — to copy, distribute and transmit the workto Remix — to adapt the work

Under the following conditions:Attribution. You must attribute the work in the manner specified by the author or licensor

(but not in any way that suggests that they endorse you or your use of the work).Share Alike. If you alter, transform, or build upon this work, you may distribute the

resulting work only under the same, similar or a compatible license.For any reuse or distribution, you must make clear to others the license terms of this work.

The best way to do this is with a link to this web page.Any of the above conditions can be waived if you get permission from the copyright holder.Nothing in this license impairs or restricts the author's moral rights.

http://creativecommons.org/licenses/by-sa/3.0/ 72

Documents

Design Patterns CSCI 6221 – Advanced Software Paradigms Fall 2014