Informatics 122 Software Design II Lecture 7 André van der Hoek Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. April 22, 2019 – 15:28:05 (c) 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Today’s Lecture Design patterns April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

Fundamental Principles Apply rigor Separate concerns modularize abstract Anticipate change Generalize Work incrementally April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

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) April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

A Checklist on Class Design Cohesion Completeness Convenience Clarity Consistency April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

A Checklist on Principles and Strategies keep it simple, stupid! (KISS) information hiding acyclic dependencies … Strategies program to the interface refactor apply software patterns use aspects April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

A Checklist on Principles and Strategies keep it simple, stupid! (KISS) information hiding acyclic dependencies … Strategies program to the interface refactor apply software patterns use aspects April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

© 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

Abstract Method (Creational, Class) Provides hooks for subclasses Can connects parallel class hierarchies April 22, 2019 – 15:28:05 © 2007 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. April 22, 2019 – 15:28:05 © 2007 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. April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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. April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

Observer (Behavioral, Object) Abstract coupling between subject and observer Support for broadcast communication Unexpected updates April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 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 April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek

© 2007 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 April 22, 2019 – 15:28:05 © 2007 University of California, Irvine – André van der Hoek