Chapter 6 Introduction to Design Patterns (Part I) COSC 4346: Software Engineering I Dr. Lappoon R. Tang.
Post on 30-Mar-2015
219 Views
Preview:
Transcript
Chapter 6Introduction to Design Patterns
(Part I)
COSC 4346: Software Engineering I
Dr. Lappoon R. Tang
Overview
Recurring Design Purposes What are Design Patterns? The abstract factory pattern
Readings
Section 6.1 Section 6.2
Review: Sample Design Goals and Ways to Accomplish Them
Reusability, Flexibility, and Maintainabilityo Reuse flexible designso Keep code at a general levelo Minimize dependency on other classes
Robustness o Reuse reliable designso Reuse robust parts
Sufficiency / Correctnesso Modularize designo Reuse trusted parts
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Case study: KitchenViewer
Suppose we want to create an application KitchenViewer that can display a design for our kitcheno Wall cabineto Countero Floor cabinet
The application can also render a style for the kitcheno Moderno Classico Antiqueo Arts & Crafts
KitchenViewer Interface
Wallcabinet
Counter
Floorcabinet
Modern Classic Antique Arts & Crafts
menu
display area
styles
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
KitchenViewer Example
Modern Classic Antique Arts & Crafts
Wall cabinets Floor cabinetsCountertop
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Selecting Antique Style
Modern Classic Antique Arts & CraftsAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goals vs. Design Purposes
A design goal (such as reusability) is generally too “high level”
When confronted with an actual design problem, one needs to translate a goal into specific design purposeo Example: A goal is to reuse a part of
a calendar application, it may be translated into a specific design purpose to parameterize a set of methods so that they can be applied to any day, month, year
Design Purpose: KitchenViewer Suppose our design goal here is
flexibility To achieve the goal, what should be
our design purpose?o Example: the procedure for rendering
various styles is basically the same, there should be no need for more than one copy of this procedure renderKitchen()
More precisely, the design purpose can be stated as follows:o An application must construct a family
of objects at runtime: The design must enable choice among several styles
What are Design Patterns?
Class combinations and accompanying algorithms that fulfill common design purposes
A design pattern expresses an idea rather than a fixed class combinationo Accompanying algorithms
express the pattern’s basic operation
What are Design Patterns?
Design patterns express an idea instead of specific detailso Example: In house building, the
term ‘ranch style’ denotes a useful house pattern; it is an idea only, the specific details in building the house according to ‘ranch style’ has yet to be worked out
Bad example first: without design patterns
// Sample code for renderKitchen() – version ignoring design purpose
// Determine the style
... // Case statement
// Assume that the antique style was selected.
// Create the antique wall cabinets
AntiqueWallCabinet antiqueWallCabinet1 = new AntiqueWallCabinet();
AntiqueWallCabinet antiqueWallCabinet2 = new AntiqueWallCabinet();
...
// Create the antique floor cabinets
AntiqueFloorCabinet ...
// Create the kitchen object, assuming the existence of add() method
Kitchen antiqueKitchen = new Kitchen();
antiqueKitchen.add(antiqueWallCabinet1, ...); // rest of parameters specify location
antiqueKitchen.add(antiqueWallCabinet2, ...);
// Add antique floor cabinets to the kitchen
...
// Render antiqueKitchen
...
Bad example first: without design patterns
renderKitchen() uses the classes Kitchen, WallCabinet, FloorCabineto This method is placed in a class
called Client (conceptually the application class or a class to be used by the application class)
As you can see, the code is going to be repetitive, inflexible, and hardly reusableo One copy of such code is needed for
every type of style (e.g. modern)
KitchenViewer Without Design Patterns
Kitchen
ClientrenderKitchen()
FloorCabinet
ModernWallCabinet
ModernFloorCabinet AntiqueFloorCabinet
AntiqueWallCabinet
WallCabinet
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goal At Work: Flexibility
Our design should be flexible enough to produce any of the several kitchen styles.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
How do we deal with the problem?
Problem: … new AntiqueWallCabinet(); Applies only to antique style because
objects of the class AntiqueWallCabinet can only access methods related to rendering antique wall cabinets
Solution: … myStyle.getWallCabinet(); The class of the object myStyle will
check at runtime which style (e.g. antique or modern?) is being rendered and then the corresponding method for rendering is used.
AntiqueKStylegetWallCabinet()getFloorCabinet()
The Abstract Factory Idea
KitchenStylegetWallCabinet()getFloorCabinet()
ModernKStylegetWallCabinet()getFloorCabinet()
WallCabinet FloorCabinet
AntiqueWallCabinet AntiqueFloorCabinet
FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); }
……
FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); }
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Abstract Factory Design Pattern Applied to KitchenViewer
KitchenStylegetWallCabinet()getFloorCabinet()
KitchengetWallCabinet()getFloorcabinet()
ClientrenderKitchen( KitchenStyle )
ModernKStylegetWallCabinet()getFloorCabinet()
AntiqueKStylegetWallCabinet()getFloorCabinet()
WallCabinet FloorCabinet
ModernWallCabinet
ModernFloorCabinet
AntiqueWallCabinet
AntiqueFloorCabinetAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Abstract Factory Design Pattern Applied to KitchenViewer
// renderKitchen(KitchenStyle* myStyle) – using design pattern
// Note: Code is adapted for C++.
// Create wall cabinets, type decided by the class of myStyle
WallCabinet* wallCabinet1 = myStyle -> getWallCabinet();
WallCabinet* wallCabinet2 = myStyle -> getWallCabinet();
...
// Create floor cabinets
FloorCabinet* floorCabinet1 = myStyle -> getFloorCabinet();
FloorCabinet* floorCabinet2 = myStyle -> getFloorCabinet();
...
Kitchen kitchen = new Kitchen();
kitchen.add(wallCabinet1, ...);
kitchen.add(wallCabinet2, ...);
... // Add floor cabinet to kitchen
Abstract Factory Design Pattern
StylegetComponentA()getComponentB()
ClientdoOperation( Style myStyle )
Style1getComponentA()getComponentB()
Style2getComponentA()getComponentB()
ComponentA ComponentB
Style1ComponentA
Style1ComponentB
Style2ComponentA
Style2ComponentB
Collection
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Abstract Factory Design PatternAlternative
StylegetComponentA()getComponentB()
ClientdoOperation()
Style1getComponentA()getComponentB()
Style2getComponentA()getComponentB()
ComponentA ComponentB
Style1ComponentA
Style1ComponentB
Style2ComponentA
Style2ComponentB
Collection getComponentA()getComponentB()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Design Pattern
-- Definition: class combination and algorithms that fulfill a common design purpose.
The abstract factory pattern:* Achieves design purposes derived from the design quality flexibility* Key ideas:
o Parameterize the methods that are supposed to be
flexible and easily extendableo Make the class containing the flexible
methods depend on or aggregate an abstract class to which
new sub-classes (thus new functionalities) can be
added.o Make the sub-classes of the abstract class
in turn depend on sub-classes of other abstract
classes needed by the design
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
top related