Computer Science 490.002Design PatternsSpring 2009 - TR 9:30-10:45 AM - EB 0011Instructor: Bill WhiteEngineering Building 3041(618)650-3483wwhite@siue.eduOffice Hours:MTWR 11AM-3PM, and by appointment!

Chapter 1 – Page 1

Tentative SyllabusWeek 1: Introduction to Patterns; Abstract Factory PatternWeek 2: Builder Pattern; Factory Method PatternWeek 3: Prototype Pattern; Singleton PatternWeek 4: Creational Pattern Review; Adapter PatternWeek 5: Bridge Pattern; Composite PatternWeek 6: Decorator Pattern; Façade PatternWeek 7: Flyweight Pattern; Proxy PatternWeek 8: Structural Patterns Review; EXAM 1Week 9: SPRING BREAKWeek 10: Chain of Responsibility Pattern; Command PatternWeek 11: Interpreter Pattern; Iterator Pattern; Mediator PatternWeek 12: Memento Pattern; Observer Pattern; State PatternWeek 13: Strategy Pattern; Template Method PatternWeek 14: Visitor Pattern; Behavioral Patterns ReviewWeek 15: Topical Paper PresentationsWeek 16: Topical Paper Presentations; EXAM 2Week 17: FINAL EXAM

GRADING• Six 50-point homework assignments• Two 100-point programming

assignments• One 100-point topical paper• One 50-point topical paper

presentation• Two 100-point exams• One 150-point comprehensive final

exam

LATE POLICYNo late assignments without verifiable medical documentation!

ACADEMIC MISCONDUCTNo one sees your code except the instructor! All designs must be original!

Chapter 1 – Page 2

Design Patterns DefinedA design pattern is a general reusable solution to a common software design problem.

Chapter 1 – Page 3

Pattern NameA descriptive

identifier for the pattern

IntentA description of the goal behind the pattern and the reasons for

using it

Implementation

A description of the solution of the

problem

Consequences

A description of the results, side

effects, and tradeoffs

associated with using the solution

Design Pattern Concept: DelegationSome programming problems may be solved by having one object defer a task to another object.

Chapter 1 – Page 4

class Zippy{ public: virtual string typeString() { return string("TYPE ZIPPY"); }};

class Whoopee{ public: Zippy zip; string typeString() { return zip.typeString(); }};

class Yippy{ public: virtual string typeString() { return string("TYPE YIPPY"); }};

class Slurpee{ public: Slurpee(Yippy* newYipPtr) : Yippy(newYipPtr) {} Yippy* yipPtr; string typeString() { return yipPtr->typeString(); }};

class Yappy : public Yippy{ public: virtual string typeString() { return string("TYPE YAPPY"); }};

...Slurpee slurp1(new Yippy);Slurpee slurp2(new Yappy);cout << slurp1.typeString() << endl;cout << slurp2.typeString() << endl;...

Output:TYPE YIPPYTYPE YAPPY

Simple example of delegation:

More useful example of delegation:

Design Pattern Concept: ConsultationWhenever extra conditions or side effects must be considered when a method is invoked, it is often useful to have a constituent object handle the details.

Chapter 1 – Page 5

message receiver

method holder

self

delegation

message receiver

method holder

self

consultation

class CustomerList{ private: List<Customer> customers = new ArrayList<Customer>(); public: void add(Customer customer) { customers.add(customer); // this is a consultation }}; Delegating a

message means asking another object to do something on behalf of the message receiver.

Consulting means asking the other

object to do something on its

own.

If the List’s add method checks whether the customer is already in the list or whether the parameterized customer is null, then the CustomerList class isn’t burdened with those details.

Design Pattern Concepts: Composition & AggregationComplicated software might be simplified by merely combining simple objects into more complex objects.

Chapter 1 – Page 6

class Professor;

class Department { ... private: // Aggregation Professor* members[5]; ...};

class University { ... private: // Composition Department faculty[20]; ... };

The University-Department association is a composition, so if a University closes, all of its Departments would be destroyed.The Department-Professor association is an aggregation, so if a Department is destroyed, its Professors would still exist.

Design Pattern Concept: InterfacesTo take full advantage of the benefits of object-oriented design and programming, the implementation of a software module should be distinguished from its interface.

Chapter 1 – Page 7

Implementation

• Actual code of procedures and methods• All private data members and member

functions• Allows for internal modification without

affecting the way outside entities interact with the module

Interface

• Provides abstraction of module to outside entities

• Restricts access to resources to well-defined entry points, such as public members

• Supports polymorphism, often via inheritance from the same abstract class

Design Pattern CategoriesClassical design patterns are separated into three categories:

Chapter 1 – Page 8

Creation

alCreating

objects in a manner suitable to the

situation

Abstract Factory

Builder

Factory MethodPrototype

Singleton

Structural

Identify

simple

ways to

realize

relationshi

ps between

entities

Adapter

Bridge

Composite

Decorator

Façade

Flyweight

Proxy

Behavioral

Identify and realize comm

on interactions

between

objects

Chain of

Responsi-

bilityComm

and

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template

Method

Visitor

RefactoringOne of the main purposes of design patterns in software engineering is refactoring, designing one’s code so internal structure of the programming can be changed without modifying its external behavior.

Chapter 1 – Page 9

Code smells are symptoms in a program that indicate that refactoring might be needed, such as:•Duplicate code• Large functions

• Large classes• Tiny classes

•Overdependence on the implementation details of another classAppropriate use of design patterns

can help avoid code smells and facilitate refactoring for program improvement.

Example: Using the Façade PatternThe Façade

Pattern provides a simple interface to an entire subsystem of objects, simplifying the use of the subsystem by reducing the need for outside code to be aware of the subsystem’s inner workings, thereby improving the readability of the clients that use the subsystem.

Chapter 2 – Page 10

Pre-Façade CompilationVarious

entities are used to convert a source program (in a high-level language like C++) into an object program (in machine language), including the lexical analyzer, the parser, and the code generator.

Chapter 2 – Page 11

Post-Façade CompilationNotice how

the insertion of the Compiler façade simplifies the interface between the client and the compilation modules, improving the ability to modify either without compelling a modification to the other.

Chapter 2 – Page 12

Other Façade Situations

A physics lab uses an elaborate scientific visualization class that applies

advanced numerical techniques to generate raw data which is converted

into graphical parameters that are rendered on a display.

Unfortunately, whenever a driver module is developed to access this

visualization class, the driver code must deal with complicated system calls to the functions in the visualization class.The lab manager has decided to have a software development team develop a new class that will convert relatively

simple driver code into the more complicated commands required by the

old visualization program.

Chapter 2 – Page 13

A mortgage company has set up a class hierarchy for determining the eligibility

of customers for home mortgages. The hierarchy includes classes for

calculating banking info (the customer’s savings and checking account histories,

current investments, and retirement funds), loan info (home equity,

automobile and consolidation loans), and credit info (current credit card debt

and payment history). To simplify the mortgage evaluation

process, the company has commissioned the development of

software that will collate this info into a single interface that its financial officers

will be able to use to more efficiently deal with customer applications.