1. 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

2. © 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. © 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. © 2007 University of California, Irvine – André van der Hoek
More…
Patterns
Interaction design patterns
Anti-Patterns
Refactoring
And numerous, numerous, numerous books
April 22, 2019 – 15:28:05
© 2007 University of California, Irvine – André van der Hoek