Chapter 6 Introduction to Design Patterns (Part I)

1
Chapter 6Introduction to Design Patterns(Part I)

• COSC 4346 Software Engineering I
• Dr. Lappoon R. Tang

2
Overview

• Recurring Design Purposes
• What are Design Patterns?
• The abstract factory pattern

3
Readings

• Section 6.1
• Section 6.2

4
Review Sample Design Goals and Ways to
Accomplish Them

• Reusability, Flexibility, and Maintainability
• Reuse flexible designs
• Keep code at a general level
• Minimize dependency on other classes
• Robustness
• Reuse reliable designs
• Reuse robust parts
• Sufficiency / Correctness
• Modularize design
• Reuse trusted parts

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
5
Case study KitchenViewer

• Suppose we want to create an application
  KitchenViewer that can display a design for our
  kitchen
• Wall cabinet
• Counter
• Floor cabinet
• The application can also render a style for the
  kitchen
• Modern
• Classic
• Antique
• Arts Crafts

6
KitchenViewer Interface
Wall cabinet
menu
?
Counter
display area
styles
Floor cabinet
Modern
Classic
Antique
Arts Crafts
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
7
KitchenViewer Example
Wall cabinets
Floor cabinets
Countertop











Modern
Classic
Antique
Arts Crafts
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
8
Selecting Antique Style











Modern
Classic
Antique
Arts Crafts
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
9
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 purpose
• 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

10
Design Purpose KitchenViewer

• Suppose our design goal here is flexibility
• To achieve the goal, what should be our design
  purpose?
• 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
• An application must construct a family of objects
  at runtime The design must enable choice among
  several styles

11
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 combination
• Accompanying algorithms express the patterns
  basic operation

12
What are Design Patterns?

• Design patterns express an idea instead of
  specific details
• 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

13
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

14
Bad example first without design patterns

• renderKitchen() uses the classes Kitchen,
  WallCabinet, FloorCabinet
• 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 reusable
• One copy of such code is needed for every type of
  style (e.g. modern)

15
KitchenViewer Without Design Patterns
Client renderKitchen()
Kitchen
FloorCabinet
WallCabinet
ModernWallCabinet
AntiqueWallCabinet
ModernFloorCabinet
AntiqueFloorCabinet
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
16
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.
17
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.

18
The Abstract Factory Idea
KitchenStyle getWallCabinet() getFloorCabinet()
WallCabinet
FloorCabinet
AntiqueWallCabinet
AntiqueFloorCabinet


ModernKStyle getWallCabinet() getFloorCabinet()
AntiqueKStyle getWallCabinet() getFloorCabinet()
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.
19
Abstract Factory Design Pattern Applied to
KitchenViewer
Client renderKitchen( KitchenStyle )
KitchenStyle getWallCabinet() getFloorCabinet()
Kitchen getWallCabinet() getFloorcabinet()
WallCabinet
FloorCabinet
ModernWallCabinet
ModernKStyle getWallCabinet() getFloorCabinet()
AntiqueWallCabinet
ModernFloorCabinet
AntiqueKStyle getWallCabinet() getFloorCabinet()
AntiqueFloorCabinet
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
20
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 -gt
  getWallCabinet()
• WallCabinet wallCabinet2 myStyle -gt
  getWallCabinet()
• ...
• // Create floor cabinets
• FloorCabinet floorCabinet1 myStyle -gt
  getFloorCabinet()
• FloorCabinet floorCabinet2 myStyle -gt
  getFloorCabinet()
• ...
• Kitchen kitchen new Kitchen()
• kitchen.add(wallCabinet1, ...)
• kitchen.add(wallCabinet2, ...)
• ... // Add floor cabinet to kitchen

21
Abstract Factory Design Pattern
Client doOperation( Style myStyle )
Style getComponentA() getComponentB()
Collection
ComponentA
ComponentB
Style1ComponentA
Style1 getComponentA() getComponentB()
Style2ComponentA
Style1ComponentB
Style2 getComponentA() getComponentB()
Style2ComponentB
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
22
Abstract Factory Design PatternAlternative
Client doOperation()
Collection getComponentA() getComponentB()
Style getComponentA() getComponentB()
ComponentA
ComponentB
Style1ComponentA
Style1 getComponentA() getComponentB()
Style2ComponentA
Style1ComponentB
Style2 getComponentA() getComponentB()
Style2ComponentB
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
23
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 extendable o 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.