(c) 2010 University of California, Irvine – André van der Hoek1June 29, 2015 – 08:55:05 Informatics 122 Software Design II Lecture 8 André van der Hoek Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

(c) 2010 University of California, Irvine – André van der Hoek2June 29, 2015 – 08:55:05 Today’s Lecture Design patterns Assignment 4

(c) 2010 University of California, Irvine – André van der Hoek3June 29, 2015 – 08:55:05 Fundamental Principles Apply rigor Separate concerns –modularize –abstract Anticipate change Generalize Work incrementally

(c) 2010 University of California, Irvine – André van der Hoek4June 29, 2015 – 08:55:05 A Checklist on Overall Design Strive for grouping related functionality (high cohesion) Strive for ungrouping semi-related functionality (high cohesion) Strive for reducing interdependency (low coupling)

(c) 2010 University of California, Irvine – André van der Hoek5June 29, 2015 – 08:55:05 A Checklist on Class Design Cohesion Completeness Convenience Clarity Consistency

(c) 2010 University of California, Irvine – André van der Hoek6June 29, 2015 – 08:55:05 A Checklist on Principles and Strategies Principles –keep it simple, stupid! (KISS) –information hiding –acyclic dependencies –… Strategies –program to the interface –refactor –apply software patterns –use aspects –…

(c) 2010 University of California, Irvine – André van der Hoek7June 29, 2015 – 08:55:05 A Checklist on Principles and Strategies Principles –keep it simple, stupid! (KISS) –information hiding –acyclic dependencies –… Strategies –program to the interface –refactor –apply software patterns –use aspects –…

(c) 2010 University of California, Irvine – André van der Hoek8June 29, 2015 – 08:55:05 Design Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [Alexander, Ishikawa, Silverstein 1977] Pattern –name –problem –solution –consequences

(c) 2010 University of California, Irvine – André van der Hoek9June 29, 2015 – 08:55:05 Software Design Patterns “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” [Gamma, Helm, Johnson, Vlissides 1995] Pattern –name and classification –intent –also known as –motivation –applicability –structure –participants –collaborations –consequences –implementation –sample code –known uses –related patterns

(c) 2010 University of California, Irvine – André van der Hoek10June 29, 2015 – 08:55:05 Patterns Are Designed to Avoid Redesign Creating an object by specifying a class explicitly Dependence on specific operations Dependence on hardware and software platform Dependence on object representations or implementations Algorithmic dependencies Tight coupling Extending functionality by subclassing Inability to alter classes conveniently

(c) 2010 University of California, Irvine – André van der Hoek11June 29, 2015 – 08:55:05 Patterns Apply Two Design Principles Program to an interface, not an implementation –interface should be separately defined, using abstract classes Favor object composition over inheritance

(c) 2010 University of California, Irvine – André van der Hoek12June 29, 2015 – 08:55:05 Original Catalogue of Patterns Purpose CreationalStructuralBehavioral ScopeClassAbstract MethodAdapter (class)Interpreter Template Method ObjectAbstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

(c) 2010 University of California, Irvine – André van der Hoek13June 29, 2015 – 08:55:05 Abstract Method (Creational, Class)

(c) 2010 University of California, Irvine – André van der Hoek14June 29, 2015 – 08:55:05 Abstract Factory (Creational, Object)

(c) 2010 University of California, Irvine – André van der Hoek15June 29, 2015 – 08:55:05 Builder (Creational, Object)

(c) 2010 University of California, Irvine – André van der Hoek16June 29, 2015 – 08:55:05 Adaptor (Structural, Object)

(c) 2010 University of California, Irvine – André van der Hoek17June 29, 2015 – 08:55:05 Composite (Structural, Object)

(c) 2010 University of California, Irvine – André van der Hoek18June 29, 2015 – 08:55:05 Decorator (Structural, Object)

(c) 2010 University of California, Irvine – André van der Hoek19June 29, 2015 – 08:55:05 Proxy (Structural, Object)

(c) 2010 University of California, Irvine – André van der Hoek20June 29, 2015 – 08:55:05 Command (Behavioral, Object)

(c) 2010 University of California, Irvine – André van der Hoek21June 29, 2015 – 08:55:05 Observer (Behavioral, Object)

(c) 2010 University of California, Irvine – André van der Hoek22June 29, 2015 – 08:55:05 State (Behavioral, Object)

(c) 2010 University of California, Irvine – André van der Hoek23June 29, 2015 – 08:55:05 Visitor (Behavioral, Object)

(c) 2010 University of California, Irvine – André van der Hoek24June 29, 2015 – 08:55:05 More… Patterns – – Interaction design patterns – Anti-Patterns – Refactoring – And numerous, numerous, numerous books

© 2010 University of California, Irvine – André van der Hoek25February 8, 2010 – 21:49:30 Assignment 4 – Design Patterns Improve the design of Calico by replacing existing structures in the UML model with appropriate patterns –start with any of the designs available to your group You should apply at least 7 different design patterns –at least three not discussed in class Each use of a pattern should be carefully motivated in a brief accompanying document

© 2010 University of California, Irvine – André van der Hoek26February 8, 2010 – 21:49:30 Assignment 4 – Design Patterns Each group must turn in: –the original UML diagram from which you started –a new UML diagram, with each pattern precisely highlighted as to where it resides in the UML diagram –a document describing  the motivation for each pattern  the impact the application of the pattern has on the original design (i.e., how far reaching is the change to incorporate the pattern?)‏ –graded on usefulness of the pattern, diversity of patterns, rationale, and level of design understanding Each person also needs to submit a team evaluation (new forms available on class webpage)‏ Printed copy due Tuesday, February 16 th at the beginning of class

© 2010 University of California, Irvine – André van der Hoek27February 8, 2010 – 21:49:30 Further Tips Read the book Discuss the patterns with each other Imagine possible changes against which you would like to insulate Try different parts of the code Use the UML