Computer Science 490.002 Design Patterns

1. 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 wwhite@siue.edu Office Hours: MTWR 11AM-3PM, and by appointment!

2. Tentative Syllabus Chapter 1 – Page 2 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 ACADEMIC MISCONDUCT No one sees your code except the instructor! All designs must be original! LATE POLICY No late assignments without verifiable medical documentation!

3. Design Patterns Defined Chapter 1 – Page 3 A design pattern is a general reusable solution to a common software design problem.

4. Design Pattern Concept: Delegation Chapter 1 – Page 4 More useful example of delegation: Some programming problems may be solved by having one object defer a task to another object. class Yippy { public: virtual string typeString() { return string("TYPE YIPPY"); } }; class Yappy : public Yippy { public: virtual string typeString() { return string("TYPE YAPPY"); } }; Simple example of delegation: class Zippy { public: virtual string typeString() { return string("TYPE ZIPPY"); } }; class Slurpee { public: Slurpee(Yippy* newYipPtr) : Yippy(newYipPtr) {} Yippy* yipPtr; string typeString() { returnyipPtr->typeString(); } }; class Whoopee { public: Zippy zip; string typeString() { returnzip.typeString(); } }; ... Slurpee slurp1(new Yippy); Slurpee slurp2(new Yappy); cout << slurp1.typeString() << endl; cout << slurp2.typeString() << endl; ... Output: TYPE YIPPY TYPE YAPPY

5. Design Pattern Concept: Consultation Chapter 1 – Page 5 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. classCustomerList { private: List<Customer> customers = newArrayList<Customer>(); public: void add(Customer customer) { customers.add(customer); // this is a consultation } }; 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. self self 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. message receiver method holder message receiver method holder delegation consultation

6. Design Pattern Concepts: Composition & Aggregation Chapter 1 – Page 6 Complicated software might be simplified by merely combining simple objects into more complex objects. 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.

7. Design Pattern Concept: Interfaces Chapter 1 – Page 7 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.

8. Design Pattern Categories Chapter 1 – Page 8 Classical design patterns are separated into three categories:

9. Refactoring Chapter 1 – Page 9 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. Code smells are symptoms in a program that indicate that refactoring might be needed, such as: • Duplicate code • Large classes • Large functions • 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.

10. Example: Using the Façade Pattern Chapter 2 – Page 10 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.

11. Pre-Façade Compilation Chapter 2 – Page 11 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.

12. Post-Façade Compilation Chapter 2 – Page 12 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.

13. Other Façade Situations Chapter 2 – Page 13 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. 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.