1. Foundations of Software Engineering Patterns - Introduction
Component
operation
Concrete Component
operation()
Concrete Dec #1
addedState
Concrete Dec #2
addedBehavior()
component
Decorator
component->operation()
Decorator::operation()

2. What Are 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.
Christopher Alexander
A pattern is a general solution to a problem in a context
general -- outline of approach only
problem -- a recurring issue
context -- consider the expected design evolution

3. Describing Patterns
Describe design patterns using a consistent format, according to the following template
A uniform structure to the information, making design patterns easier to learn, compare, and use
Pattern name and classification
Intent
Also known as …
Motivation
Applicability
Structure
Participants
Collaboration
Consequences
Implementation
Sample code
Known Uses
Related Patterns

4. Patterns allow us to gain from the experience, and mistakes, of others.
Design for re-use is difficult
Experienced designers:
Rarely start from first principles
Apply a working "handbook" of approaches
Patterns make this experiential knowledge available to all
Support evaluation of alternatives at higher level of abstraction

5. The most important piece of information about a pattern is its intent.
The intent provides the general indication of when a pattern may be appropriate.
Some intentions may be familiar sounding while others are not.
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

6. Patterns Organized by Purpose and Scope
[GoF]

7. The main classification for Gang-of-Four design patterns is by purpose of the pattern’s intent.
Creational: intent is mainly about creating objects
Structural: intent is mainly about the structural relationship between the objects
Behavioral: intent is mainly about the interactions between the objects

8. A second dimension for classification is binding time.
Using inheritance is compile-time (early) binding or class-based
Using delegation or composition is run-time (late) binding or object-based
Creational
class => defer creation to subclasses
object => defer creation to another object
Structural
class => structure via inheritance
object => structure via composition
Behavioral
class => algorithms/control via inheritance
object => algorithms/control via object groups

9. Patterns Organized by Purpose and Scope
[GoF]

10. Pattern Relationships

11. To apply a pattern you need to, at least, know structure, participants, and collaborations.
The static class relationships between elements of the pattern.
Note: GoF structure is not standard UML notation
Participants
Each class/object in the patterns
The responsibilities for each class/object
Collaborations
General description of interactions between participants
Sequence diagram defining interactions

12. The consequences describe the nuances of the pattern usage.
How does the structure support the intent of the pattern?
What are the trade-offs in pattern usage?
Where are the variation points?

13. The implementation details can be language specific.
Pitfalls to avoid when implementing the pattern
Hints and techniques for applying the pattern
Language-specific design choices

14. Describing Design Patterns
How do we describe design patterns? Graphical notations, while important and useful, aren't sufficient. They simply capture the end product of the design process as relationships between classes and objects.
To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it.
Concrete examples are important too, because they help you see the design in action.

15. Composite

16. Composite Intent
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
(Structural)

17. Composites let you represent the small and big pieces “exactly” the same way.
Everything is a Component!
Component
children
Leaf (a)
Leaf (b)
Leaf (c)
Composite
Lots of types of elementary leaves which are all components.
The composite is a collection of components.

18. Composites deal with children
One of your design choices is what should be on the component interface.
Composites deal with children
Child-related operations on the Component interface
What does that mean for a Leaf?
Only on the Composite interface
When are you dealing with a Composite?
Everything is not a Component.
Leaf-specific operations
On the Component interface
Lot’s of leaves  large component interface
Only on the Leaf interface
What Leaf are you dealing with?

19. You can tell this from the UML notation
Who should be responsible for deleting child objects when composite is deleted?
You can tell this from the UML notation
Aggregation
Composition
What is the nature of the part-whole relationship?

20. Observer

21. Observer Intent
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
(Behavioral)

22. The Observer pattern allows observers to monitor state changes in a subject object.
Did something happen?
I did not see anything. The sun was in my eyes.
I’m interested!
How many spots?
I wish I did not have to keep watching.
I’ll register too.
Me too!
I am such a popular subject maybe I’ll start tweeting!
Subject
Subject
Hey, I changed.
I have four spots.
This slide has a large animation sequence in it. It has the following stages:
It starts with the subject with four blue circles, and the four observers.
Click to get something to happen to the subject.
A kick boxer moves the box to the left and one blue spot disappears. Two seconds later the observers start wondering if something just happened to the subject. Click to remove comments.
In this age of social networking, the subject has an idea. Click to see the idea.
Click to get the observers’ responses. Click to remove the responses.
Now everything is set up and waiting.
The kick boxer moves the box again, and the fourth blue spot comes back. Two seconds later the notifications start.
The subject notifies the top observer of a change. The observer queries the subject, and gets status information back.
The left observer receives the change notice, but does not need to query to subject about the details of the change.
The right and bottom observers are pushed the exact information about the changes that happened in the subject.
I think I saw it.
Sign me up!

23. There are two ways that updates can be done.
Pull
After update, observer queries ("pulls from") subject for information needed.
Push
Subject sends ("pushes") data payload with update

24. myState = subject->getState()
Observer Structure
Subject
attach(Observer)
detach(Observer)
notify()
observers
Observer
update()
for ( o in observers ) {
o->update() }
update()
myState
ConcObserver
ConcSubject
getState()
subjectState
subject
myState = subject->getState()
How does Java support this?

25. Observer Collaborations

26. Subject has large number of state changes.
In some systems with a lot of change activity, you will want to reduce the number of updates.
Subject has large number of state changes.
Allow observer to register for the subset of changes that it cares about.
Subjects have interdependencies for state changes.
Use a Mediator to update observers once all subjects are modified.

27. Iterator

28. Why do we need iterators?
Changes to consider
Why do we need iterators?
Don't require clients to do the heavy lifting
Provide clients with special iteration capabilities that the problem requires
Don't just rely on foreach constructs
Merging two ordered collections
Lighten discussion of separate vs embedded iterators
Emphasize internal vs external control with strategy for selection or processing

29. Iterator Intent
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
(Behavioral)

30. What do the Java Collection Framework iterators provide for you?
Function to call to get iterator
Iterator implements a standard interface
Common approach to access elements in the collection

31. Iterator Structure Collection Iterator Client first() createIterator()
next()
isDone()
currentItem()
Client
List
ListIterator
Stack
StackIterator

32. Iterators are classified along two dimensions.
Iterator is embedded in the collection object
Location of iterator
Iterator is a separate class from the collection class
Control is external to iterator, i.e. iterator client has control
Location of iteration control
Control is internal to iterator, i.e. iterator has control

33. The iterator definition can be embedded within the collection class.
One iterator characteristic is the location of the iterator class with respect to the collection class.
The iterator definition can be in a class separate from the collection.
Good separation of concerns: traversal vs. maintenance of collection structure
Multiple traversal types (forward, backward, matching) without unneeded ones
Easier to do multiple traversals at the same time
The iterator definition can be embedded within the collection class.
Preserves encapsulation of collection

34. Consider the Java Collection Framework:
Who controls iteration when you use the Java Collections Framework iterators?
Consider the Java Collection Framework:
Iterator iter = theCollection.iterator();
while( iter.hasNext() ) {
process( iter.next() ); }
Internal or external?
Embedded or separate?

35. Internal iterators require the client to provide a processing function.
Iterator has a function to perform iteration
public interface InternalIterator {
public boolean iterate(Processor p) ; }
Client requests that the iterator iterate through the collection and process each object
public interface Processor {
public boolean process(Object o) ;

36. The client has no iteration control with an internal iterator except to possibly terminate early.
public class ACollectionIterator implements InternalIterator {
private SomeCollection theCollection;
public ACollectionIterator(SomeCollection c) {
theCollection = c; }
public boolean iterate(Processor p) {
boolean result = true;
Start at the beginning of theCollection
while ( still elements && result) {
if ( ! p.process( next element ) ) {
result = false;
Move to the next element
return result;

37. External iterators are more flexible
There are advantages and disadvantages with external and internal iterators.
External iterators are more flexible
Example: Compare two lists for equality
Internal iterators are easier to use
Iteration logic handled for client

38. Recursive collections, such as Composites, present special problems for iteration.
Does the Java Collections Framework directly support internal or external iteration?
Which form of iterator is easier to implement when traversing a recursive collection like a tree?
Can you do the traversal with the other approach, and if so, what issues arise?

39. It is easier to iterate through a recursive collection with an internal iterator.
External iterator
iterator stores path for retreat (Hansel & Gretel)
composite provides back links for iterator to use (parent / sibling / children )
Internal iterator
Traverse recursively – get backtrack for free
Get iterator for children of current element
Use null iterators at leaves.

40. Iterator determines next element Collection determines next element
Placement of knowledge of how to do traversal involves trade-offs of O-O design principles.
Iterator determines next element
Collection determines next element
Here iterator needs to know structure of collection
Violates encapsulation of collection if a separate iterator
Iterator is just a marker/cursor of where traversal left off
Traversal logic is in the collection even if a separate iterator
Complicates collection itself
Does not separate iteration from collection maintenance

41. Smalltalk Model View Control as a Combination of GoF Patterns
From GoF Design Patterns Introduction Chapter

42. MVC User Interface Architecture Pattern
Three kinds of objects
Models: application object(s)
Views: screen presentation(s)
Controls: how to react to user input(s)

43. Decouple Models from Views via Observer
Observers
Subject

44. Views Can Be Nested: Composite
Example: a control panel of buttons

45. Change the Way a View Responds to Input
View uses an instance of a Controller subclass to implement a particular response strategy
For example, change the way it responds to keyboard input, or have it use a pop-up window instead of command keys
Command pattern is also relevant

46. Other Patterns Used
Factory Method to specify the default controller class for a view
Decorator to add scrolling to a view