Informatics 122 Software Design II Lecture 5 André van der Hoek Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. November 28, 2018 – 23:29:44 (c) 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Today’s Lecture Design patterns Assignment 3 November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Fundamental Principles Rigor Separation of concerns modularity abstraction Anticipation of change Generality Incrementality November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

During the Design Process Strive for grouping related functionality (high cohesion) Strive for ungrouping semi-related functionality (high cohesion) Strive for reducing interdependency (low coupling) November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Class Design Cohesion Completeness Convenience Clarity Consistency November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek 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 November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

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 November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

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 November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

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 November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Original Catalogue of Patterns Purpose Creational Structural Behavioral Scope Class Abstract Method Adapter (class) Interpreter Template Method Object Abstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Abstract Method (Creational, Class) Provides hooks for subclasses Can connects parallel class hierarchies November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Abstract Factory (Creational, Object) It isolates concrete classes It makes exchanging product families easy. It promotes consistency among products. Supporting new kinds of products is difficult. November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Builder (Creational, Object) It let’s you vary a product’s internal representation. It isolates code for construction and representation. It gives you finer control over the construction process. November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Adaptor (Structural, Object) Let’s a single Adapter work with many Adaptees Makes it harder to override November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Composite (Structural, Object) Defines class hierarchies consisting of primitive objects and composite objects Makes the clients simple Makes it easier to add new kinds of components Can make your design overly general November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Decorator (Structural, Object) More flexible than static inheritance Avoids feature-laden classes high up in the hierarchy A decorator and its component aren’t identical Lots of little objects November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Proxy (Structural, Object) A remote proxy can hide the fact that an object resides in a different address space A virtual proxy can perform optimizations such as creating an object on demand Both protection proxies and smart references allow additional housekeeping tasks when an object is accessed. November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Command (Behavioral, Object) Command decouples the object that invokes the operation from the one that knows how to perform it Commands are first-class objects. They can be manipulated and extended like any other object You can assemble commands into a composite command It’s easy to add new Commands, because you don’t have to change existing classes November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Observer (Behavioral, Object) Abstract coupling between subject and observer Support for broadcast communication Unexpected updates November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

State (Behavioral, Object) Localizes state-specific behavior and partitions behaviors for different states It makes state transitions explicit State objects can be shared November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

Visitor (Behavioral, Object) Visitor makes adding new components easy A visitor gathers related operations and separates unrelated ones Adding new ConcreteElement classes is hard Visiting across class hierarchies Accumulating state Breaking encapsulation November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek More… Patterns http://en.wikipedia.org/wiki/Software_pattern http://c2.com/ppr/ Interaction design patterns http://en.wikipedia.org/wiki/Interaction_design_pattern Anti-Patterns http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Refactoring http://en.wikipedia.org/wiki/Refactoring And numerous, numerous, numerous books November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Assignment 3 Refine the official design of Theseus and the Minotaur (as provided on the course web site) by furnishing any missing classes, methods, and local variables applying design patterns to improve the structure of the design Deliverables a print-out of your final UML design a print-out of your design rationale which critical decisions did you make, and why? Print-outs are to be handed in in class November 28, 2018 – 23:29:44 © 2006 University of California, Irvine – André van der Hoek