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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. © 2006 University of California, Irvine – André van der Hoek
More…
Patterns
Interaction design patterns
Anti-Patterns
Refactoring
And numerous, numerous, numerous books
November 28, 2018 – 23:29:44
© 2006 University of California, Irvine – André van der Hoek

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