computer science 490.002 design patterns
DESCRIPTION
Computer Science 490.002 Design Patterns. Chapter 1 – Page 1. Spring 2009 - TR 9:30-10:45 AM - EB 0011. Instructor: Bill White Engineering Building 3041 (618)650-3483 [email protected] Office Hours: MTWR 11AM-3PM, and by appointment!. Tentative Syllabus. Chapter 1 – Page 2. - PowerPoint PPT PresentationTRANSCRIPT
Computer Science 490.002Design PatternsSpring 2009 - TR 9:30-10:45 AM - EB 0011Instructor: Bill WhiteEngineering Building 3041(618)[email protected] 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.