design patterns
DESCRIPTION
Design Patterns. Introduction. Course Description. Traditionally, OO designers have developed their own private "catalogs" of solutions to recurring design problems. More recently, advocates of design patterns have created public repositories of patterns that more formally - PowerPoint PPT PresentationTRANSCRIPT
DESIGN PATTERNSIntroduction
COURSE DESCRIPTION Traditionally, OO designers have developed their
own private "catalogs" of solutions to recurring design problems.
More recently, advocates of design patterns have created public repositories of patterns that more formally Identify these recurring design problems Document possible solutions to these problems
through the general arrangement and composition of objects and classes
Discuss the advantages and disadvantages of the various solutions and
Provide implementation examples. This course will introduce the student to the concept of design patterns, examine several patterns in detail, apply these patterns to specific problems, and point the student to design pattern resources. 2
RECOMMENDED TEXTBOOKS Recommended Text
Design Patterns: Elements of Reusable Object-Oriented Software (1995) by Gamma; ISBN 0-201-63361-2 published by Pearson Education
Additional Reading Head First Design Patterns (2004) by Freeman;
ISBN 0-596-00712-4 published by O'Reilly and Assoc.
3
MARKS DISTRIBUTION 6-8 Quizzes: 15% 2 Assignments: 25% Mid term Exam:30% Final Exam: 30%
4
OUTLINE Introduction to Design Patterns
Describing Design Patterns The Design Patterns Catalog How to Select and Use a Design Pattern
Creational Patterns Abstract Factory, Builder, Singleton etc.
Structural Patterns Adapter, Bridge, Composite etc.
Behavioral Patterns Command, Interpreter, Observer, Strategy etc.
5
WHAT’S A GOOD OBJECT ORIENTED DESIGN
Design should be SPECIFIC to the problem at hand
AND Also be GENERIC enough to address future
problems and requirements So the design should be REUSABLE Expert designers REUSE successful designs Consequently REUSABLE designs are
recurring PATTERNS of classes and objects in OO Systems 6
REUSABILITY EXAMPLE
Novelists & Playwrights seldom write from scratch
INSTEAD
Follow PATTERNS like ‘Tragically flawed Hero’ (Macbeth, Hamlet) or ‘The Romantic Novel’
7
WHAT IS A DESIGN PATTERN “A proven solution to a common problem in a specified context.” Example: We can light a candle if light goes out at night Christopher Alexander (Civil Engineer) in 1977 wrote
“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”
The “gang of four” (GoF) In 1995, the principles that Alexander established were
applied to software design and architecture. The result was the book:
“Design Patterns: Elements of Reusable Object-Oriented
Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
8
WHY LEARN DESIGN PATTERNS They make it easier to reuse successful
designs and architectures They can make documentation and
maintenance of the systems easier Design Patterns help a designer design
“right” faster They provide a vocabulary that can be used
amongst software developers. Enable us to discuss low-level implementation
in a high-level, abstract manner. Help in extendibility and avoiding solution
redesign 9
ELEMENTS OF A DESIGN PATTERN Pattern Name
Is a handle to describe design problem & solution Problem
Describes when a Pattern is to be applied Solution
General arrangement of elements to solve a problem
Consequences Results and Tradeoffs of applying a Pattern Tradeoffs can be space, time, language etc.
10
DESCRIBING A DESIGN PATTERN Pattern Name & Classification – Conveys the
essence of the pattern concisely Intent – What design issue the pattern addresses Also Known As – Other well known names for this
pattern Motivation – A scenario illustrating a design
problem and how its being solved by the pattern Applicability – Known situations where the
pattern can be applied Structure – OMT (Object Modeling ) based graphic
representation of the classes in the pattern Participants – Classes and objects in the pattern
with their responsibilities 11
DESCRIBING A DESIGN PATTERN CONT’D Collaborations – How the participants
collaborate to carry out their responsibilities Consequences – What are the results and
tradeoffs of using the pattern Implementation – Hints on implementation
of the pattern like language dependency Sample Code – Sample code Known Uses – Examples Related Patterns – Other patterns closely
related with the pattern under consideration12
NOT A DESIGN PATTERN Linked Lists Hash Tables Domain Specific designs for entire
application or subsystem A code solution ready for copy-and-paste Programming language features The same every time you see them
13
MVC PATTERN The main purpose of using MVC pattern is to decouple
the GUI from the Data. It also gives the ability to provide multiple views for the
same Data. MVC pattern separates views and models by
establishing a subscribe/notify protocol amongst them Application of MVC pattern has benefits like
Classes defining application data and presentation can be reused.
Change in one view automatically reflected in other views. Also, change in the application data is reflected in all views.
Defines one-to-many dependency amongst objects so that when one object changes its state, all its dependents are notified 14
MVC PATTERN CONT’D
A=10%B=40%C=30%D=20%
Application data
A
BC
D
A DCB
Relative Percentages
Y 10 40 30 20
X 15 35 35 15
Z 10 40 30 20
A B C D
Change notification
Requests, modificationsModel
15
MVC PATTERN CONT’D Model: - This section is specially for maintaining data. It is
actually where your business logic, querying database, database connection etc. is actually implemented.
Views: - Displaying all or some portion of data, or probably different view of data. View is responsible for look and feel, Sorting, formatting etc.
Controller: - They are event handling section which affects either the model or the view. Controller responds to the mouse or keyboard input to command Model and View to change. Controllers are associated with views. User interaction triggers the events to change the Model, which in turn calls some methods of Model to update its state to notify other registered Views to refresh their display.
16
DESIGN PATTERNS CLASSIFICATION
According to the GOF, the design patterns can be classified in two ways According to the PURPOSE According to the SCOPE
PURPOSE of Design Patterns reflect what actually they do
SCOPE of Design Patterns reflect whether they apply primarily to Classes or Objects.
17
PURPOSE BASED DESIGN PATTERNS CLASSIFICATION Creational – Concerned with the purpose of
object creation or class instantiation Structural – Deal with composition of classes
and objects
Behavioral – Characterize the ways in which classes and objects interact and distribute resposibility.
18
SCOPE BASED DESIGN PATTERNS CLASSIFICATION Class Patterns deals with the relationships
amongst the classes and their subclasses These relationships are established through
INHERITANCE, so they are static – fixed at compile time
Object Patterns deals with object relationships which can be changed at runtime or are dynamic
Note that most patterns are object patterns
19
PURPOSE & SCOPE BASED DESIGN PATTERNS CLASSIFICATION Creational Class patterns defer some part of
object creation to subclasses where as creational object patterns defer it to another object.
Structural class patterns use inheritance to compose classes, while structural object patterns describe ways to assemble objects.
Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the behavioral object patterns describe how a group of objects cooperate to perform a task 20
DESIGN PATTERNS CLASSIFICATIONPurpose
Creational Structural BehavioralScop
eClass Factory Method Adapter(Class) Interpreter
Template Method
Object
Abstract FactoryBuilderPrototypeSingleton
Adapter(Object)BridgeCompositeDecoratorFaçadeFlyweightProxy
Chain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor
21
HOW DESIGN PATTERNS SOLVE DESIGN PROBLEMS Finding appropriate objects
The hard part about OOD is decomposing a system into objects
They help to introduce an abstraction for treating objects uniformly that doesn’t have a physical counterpart
They help to identify less obvious abstractions and objects that can capture them
These objects are seldom identified in a design earlier and are discovered while making the design reusable and more flexible
Determining the object Granularity They help in specifying how to represent complete
subsystems as objects They help you in decomposing objects into smaller
objects
22
HOW DESIGN PATTERNS SOLVE DESIGN PROBLEMS Specifying Object Interfaces
Help you in defining interfaces and the kinds of data that get sent across them
Might also tell what NOT to put into an interface Also specify relationships across interfaces
Designing for Change Help you to avoid dependence on specific
operations Help you to avoid dependence on hardware and
software platforms Help to avoid algorithmic dependencies
23
PATTERNS AND ALGORITHMS Algorithms and data structures generally
solve more fine-grained computational problems like sorting and searching.
Patterns are typically concerned with broader architectural issues that have larger-scale effects.
24
PATTERNS AND FRAMEWORKS A software framework is a set of cooperating
classes that make up a reusable design for a specific class of software [Deu89,JF88]
A framework will dictate overall structure, partitioning of classes and objects, how the classes or objects collaborate
A framework is usually not a complete application: it often lacks the necessary application-specific functionality.
Examples Framework for building compiler for different
languages and machines. For building financial modeling applications 25
PATTERNS AND FRAMEWORKS Design patterns may be employed both in the design
and the documentation of a framework. A single framework typically encompasses several design patterns. A framework can be viewed as the implementation of a system of design patterns.
Frameworks and design patterns are distinct: a framework is executable software, design patterns represent knowledge and experience about software. Frameworks are of a physical nature, patterns are of a logical nature: frameworks are the physical realization of one or more software pattern solutions; patterns are the instructions for how to implement those solutions.
Major differences: Design patterns are more abstract than frameworks. Design patterns are smaller architectural elements than
frameworks. Design patterns are less specialized than frameworks. 26
AN EXAMPLE CASE
Goals Learn how to exploit and gain experience of
others Examine the benefits of design pattern Learn one specific pattern: Strategy pattern
27
SIMPLE SIMULATION OF DUCK BEHAVIOR
Duck
quack()swim()display()// other duck methods
MallardDuck
display()// looks like mallard
RedheadDuck
display()// looks like redhead
Other ducktypes
28
SIMPLE SIMULATION OF DUCK BEHAVIOR All ducks Quack and Swim the super class
DUCK takes care of the implementation code. But
Each duck subtype is responsible for implementing its own Display method as each duck looks different
In the super class the Display method is abstract.
29
WHAT IF WE WANT TO SIMULATE FLYING DUCKS?
Duck
quack()swim()display()fly()// other duck methods
MallardDuck
display()// looks like mallard
RedheadDuck
display()// looks like redhead
Other ducktypes
30
TRADEOFFS IN USE OF INHERITANCE AND MAINTENANCE
Duck
quack()swim()display()fly()// other duck methods
MallardDuck
display()// looks like mallard
RubberDuck
quack()//overridden to squeakdisplay()// looks like rubberduckfly()// override to do nothing
RedheadDuck
display()// looks like redhead
One could override thefly method to the appropriatething – just as the quackmethod below.
31
EXAMPLE COMPLICATED: ADD A WOODEN DECOY DUCKS TO THE MIX
DecoyDuck
quack(){// override to do nothing}display()// display decoy duckfly (){//override to do nothing}
Inheritance is not always the rightanswer. Every new class that inheritsunwanted behavior needs to beoverridden.
How about using interfaces instead?
32
USING INTERFACES IN OUR EXAMPLE We can take Fly() out of the superclasses We make an interface iFlyable containing the
Fly() method. That way the ducks supposed to fly can implement that interface and have a Fly() method
Same solution can be implemented for Quack(), we can make interface iQuackable containing the Quack() method
33
DUCK SIMULATION RECAST USING INTERFACES
Duck
swim()display()// other duck methods
MallardDuck
display()fly()quack()
Quackable
quack()
Flyable
fly()
RedheadDuck
display()fly()quack()
RubberDuck
display()quack()
DecoyDuck
display()
Interfaces
34
PROS & CONS Not all inherited methods make sense for all
subclasses – hence inheritance is not the right answer
But by defining interfaces, every class that needs to support that interface needs to implement that functionality… destroys code reuse and creates a maintenance issue.
So if you want to change the behavior defined by interfaces, every class that implements that behavior may potentially be impactedAND
Change is constant in Software Development Overtime an application must change and
grow or it will die… 35
DESIGN PRINCIPLES TO THE RESCUE
Identify the aspects of your application that vary and separate them from what stays the same.
OR Take the parts that vary and encapsulate
them, so that later you can alter or extend the parts that vary without affecting those that don’t.
Program to an interface, not to an implementation (Discussed Later)
36
CHANGE IN DUCK CLASSES ACCORDING TO THE DESIGN PRINCIPLE As far as we can tell other than the problems
with Fly() and Quack() the Duck Class is fine. Now to separate “the parts that change from
those which remain the same”, we can create two sets of classes apart from the Duck Class.
One set can represent the Quacking behaviors e.g. a class implements quacking, another implements squeaking etc.
Similar is the case with Flying behaviors37
38
DESIGN PRINCIPLE Program to an interface, not to an
implementation We will use interfaces to represent each behavior Each Implementation of behavior will implement
these interfaces So the duck classes won’t implement these
interfaces instead the set of classes for behavior would implement them.
With our new design the duck classes would USE a behavior represented by an interface. OR
The actual implementation won’t be locked in the duck classes.
39
IMPLEMENTING DUCK BEHAVIORS - REVISITED
FlyWithWings
fly(){// implements duckflying}
<<interface>>FlyBehavior
fly()
<<interface>>QuackBehavior
quack()
Quack
quack(){// implements duckquacking}
FlyNoWay
fly(){// do nothing – Can’t fly}
Squeak
quack(){// implements ducksqueak}
MuteQuack
quack(){// do nothing –Can’t quack}
Key now is that Duck class will delegate its flying and quacking behavior instead of implementing
these itself40
IN THE DUCK SIMULATION CONTEXT…
41
Duck
FlyBehavior: flyBehaviorQuackBehavior: quackBehavior
performQuack()swim()display()performFly()//other duck-like methods
DuckBehaviors
41
DUCK SIMULATION RECAST USING THE NEW APPROACH
42
MallardDuck
display()
RedHeadDuck
display()
RubberDuck
display()
DecoyDuck
display()
Duck
FlyBehavior: flyBehaviorQuackBehavior: quackBehavior
performQuack()performFly()setFlyBehavior()setQuackBehavior()swim()display()
<<interface>>FlyBehavior
fly()
FlyWithWingsfly()// implements duckflying
FlyNoWayfly()// do nothing –Can’t fly
<<interface>>QuackBehaviorquack()
Quackquack()// implements duckquacking
Squeakquack()// implements squeak
Mutequackquack()// do nothing
DESIGN PRINCIPLE Favor composition over inheritance HAS-A can be better than IS-A Composition lets you encapsulate a family of
algorithms into their own set of classes. Allows changing behavior at run time
43
THE STRATEGY PATTERN
44
The Strategy Pattern defines a family of algorithms, Encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.