2. Computer Science 490.002 Design Patterns Spring 2009 - TR 9:30-10:45 AM - EB 0011 Instructor: Bill White Engineering Building 3041 (618)650-3483 wwhite@siue.edu Office Hours: MTWR 11AM-3PM, and by appointment! C h a p t e r 1 – P a g e 1

3. Tentative Syllabus Week 1:Introduction to Patterns; Abstract Factory Pattern Week 2:Builder Pattern; Factory Method Pattern Week 3:Prototype Pattern; Singleton Pattern Week 4:Creational Pattern Review; Adapter Pattern Week 5:Bridge Pattern; Composite Pattern Week 6:Decorator Pattern; Façade Pattern Week 7:Flyweight Pattern; Proxy Pattern Week 8:Structural Patterns Review; EXAM 1 Week 9:SPRING BREAK Week 10:Chain of Responsibility Pattern; Command Pattern Week 11:Interpreter Pattern; Iterator Pattern; Mediator Pattern Week 12:Memento Pattern; Observer Pattern; State Pattern Week 13:Strategy Pattern; Template Method Pattern Week 14:Visitor Pattern; Behavioral Patterns Review Week 15:Topical Paper Presentations Week 16:Topical Paper Presentations; EXAM 2 Week 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 POLICY No late assignments without verifiable medical documentation! ACADEMIC MISCONDUCT No one sees your code except the instructor! All designs must be original! C h a p t e r 1 – P a g e 2

4. Design Patterns Defined A design pattern is a general reusable solution to a common software design problem. C h a p t e r 1 – P a g e 3 Pattern Name A descriptive identifier for the pattern Intent A 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

5. Design Pattern Concept: Delegation Some programming problems may be solved by having one object defer a task to another object. C h a p t e r 1 – P a g e 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 YIPPY TYPE YAPPY Simple example of delegation: More useful example of delegation:

6. Design Pattern Concept: Consultation Whenever 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. C h a p t e r 1 – P a g e 5 message receiver method holder message receiver method holder class CustomerList { private: List customers = new ArrayList (); 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.

7. Design Pattern Concepts: Composition & Aggregation Complicated software might be simplified by merely combining simple objects into more complex objects. C h a p t e r 1 – P a g e 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.

8. Design Pattern Concept: Interfaces To take full advantage of the benefits of object- oriented design and programming, the implementation of a software module should be distinguished from its interface. C h a p t e r 1 – P a g e 7 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 Implementation 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 Interface

9. Design Pattern Categories Classical design patterns are separated into three categories: C h a p t e r 1 – P a g e 8 Creational Creating objects in a manner suitable to the situation Abstract Factory Builder Factory Method Prototype Singleton Structural Identify simple ways to realize relationships between entities Adapter Bridge Composite DecoratorFaçade Flyweight Proxy Behavioral Identify and realize common interactions between objects Chain of Responsi- bility Command Interpreter Iterator Mediator MementoObserver State Strategy Template Method Visitor

10. Refactoring One 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. C h a p t e r 1 – P a g e 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 class Appropriate use of design patterns can help avoid code smells and facilitate refactoring for program improvement.

11. Example: Using the Façade Pattern The 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. C h a p t e r 2 – P a g e 10

12. Pre-Façade Compilation Various 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. C h a p t e r 2 – P a g e 11

13. Post-Façade Compilation Notice 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. C h a p t e r 2 – P a g e 12

14. 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. C h a p t e r 2 – P a g e 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.