Review of Quality Attributes Recall CISC 323 Requirements - - PowerPoint PPT Presentation

SLIDE 1

CISC 323 Intro to Software Engineering

Week 6: Design Patterns

CISC 323 Intro to Software Engineering

Lecture 6-1 Introduction to Design Patterns

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍ ✑

• ✒

☛ ☛ ✓ ✔ ✕ ✕ ✖ ✖ ✗ ✙ ✝ ✗ ✚ ✂ ✄ ✄☎ ✝ ✂ ✗ ✙✛ ✕ ✜ ✙ ✟ ✝ ✙ ✑

• Review of Quality Attributes
• Recall

– Requirements analysis determines desired quality attributes of system – When designing system, attempt to

✣ ✤ ✥ ✦ ★ ✩ ✪ ✫ ✬ ✮ ✯ ✦ ✮✰ ✱ ✫ ✯ ✪ ✰ ✲ ✳ ✴ ✦ ✯ ✦ ✵ ✶ ✮ ✷ ✪ ✩ ✬ ✮ ✩ ✩ ✯ ✪ ✸ ✶ ✩ ✦ ✰ ✹ ✮ ✬ ★ ✱ ✩ ✸ ✦ ✹✦ ✩ ✺ ✻ ✦ ✥ ✶ ✼ ✦ ✯ ✪ ✰ ✲ ✩ ✴ ✯ ✱ ✶ ✽ ✴✥ ✦ ✰ ✪ ✽ ★ ✼ ✴ ✱ ✪ ✼ ✦ ✰

– Some attributes amenable to mathematical expression (performance, availability), others less so (modifiability)

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Example Quality Attributes

• Performance
• Availability
• Security
• Modifiability
• Usability
• Testability

SLIDE 2

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Design Choices Trade Off Quality Attributes

• E.g., to obtain performance, may need to use

a very complex algorithm, reducing modifiability

• E.g., to obtain availability, may need to

replicate data sources, reducing security

• Therefore, design choices rely on knowing

required targets for quality attributes

– At what point is security sufficient? – At what point is system sufficiently fast? – … Etc.

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Design Patterns

• Software architecture normally covers the

large-scale design of software systems

• Within architectural components, it can be

useful to apply micro-architectures to help design these components

– Sometimes called design patterns

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Design Patterns

• A design pattern is a set of rules of how to

structure code in order to solve a particular class of problem

• Provides vocabulary to discuss design
• Particularly suited to OO design as patterns

can be expressed in terms of classes, associations

• Design patterns normally help in improving at

least one quality attribute, perhaps at the expense of others

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Example: the Publish and Subscribe Design Pattern

• Problem

– A data source is shared by a number of clients – Multiple clients depend on the value of the data source – Modifiability attribute important

SLIDE 3

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Concrete Example: Expense Report

Item $US Cost $Cdn Cost Total cost ($Cdn) Air $670 $670 Hotel $980 $1470 Meals $70 $105 TOTAL $1050 $670 $1245

Forms-based interface for calculating expense reports.

• ✁

✁ ✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Concrete Example: Expense Report

Item $US Cost $Cdn Cost Total cost ($Cdn) Air $670 $670 Hotel $980 $1470 Meals $70 $105 TOTAL $1050 $670 $1245

Items depend on value of exchange rate. If exchange rate changes, these values should change too.

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Dependencies

Exchange Rate $Cdn cost of hotel $US cost of hotel $Cdn cost of meals $US cost of meals depends depends depends depends

• ✒

✁ ✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Problem

• When exchange rate modified, must update values of

all components that depend on it

• ✁

✂ ✄ ✆ ✄ ✝ ✞ ✆ ✄ ✟ ✠ ✡ ☛ ☞ ✌ ✞ ✍ ✍ ✂ ✎ ✏ ✂ ✏ ✞ ✟✒ ✞ ✌ ✄ ✌ ☛ ✡ ✓ ✄ ✒ ✄ ✌ ✓ ✞ ✌ ✄ ✔ ✏ ✂ ✕ ✌ ✖✄ ✆ ✕ ☛ ✄

• ✁

✂ ✎ ✡ ✏ ✕ ✠ ✡ ✄ ✡ ✖ ✆ ✄ ✕ ☛ ✒ ✆ ✞ ✗✘ ✄ ✟ ✡ ✎ ✌ ✟ ✞ ✓ ✎ ✝ ✎ ✕ ✗ ✎ ✘ ✎ ☛ ✙

Exchange Rate $Cdn cost of hotel $US cost of hotel $Cdn cost of meals $US cost of meals depends depends depends depends

SLIDE 4

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁✒ ✁

Solution: Publish and Subscribe Design Pattern

• A source component

contains data on which a set of client components depend (e.g., current exchange rate)

• The client components

subscribe to changes in the data

• The source component

publishes any changes in the data

Exchange Rate $Cdn cost of hotel (1) Client component subscribes to changes in exchange rate (2) Source component publishes changes in exchange rate

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁✒ ✁

Solution: Publish and Subscribe Design Pattern

• Advantages
• ✁

✠ ✗✘ ✎ ✡ ✂ ✄ ✆ ✏ ✞ ✓ ✄ ✓ ✞ ✄ ✡ ✌ ✞ ☛ ✓ ✄ ✒ ✄ ✌ ✓ ✞ ✌ ✍ ✂ ✞ ✡ ✠ ✗ ✡ ✏ ✆ ✎ ✗ ✄ ✆ ✡ ✕ ✆ ✄

• ✁

✂ ✄ ✆ ✄ ✝ ✞ ✆ ✄ ✏ ✕ ✌ ✕ ✓ ✓ ✕ ✆ ✗ ✎ ☛ ✆ ✕ ✆ ✙ ✡ ✠ ✗ ✡ ✏ ✆ ✎ ✗ ✄ ✆ ✡ ✕ ☛ ✆ ✠ ✌ ☛ ✎ ✟✄

• ✂

✞ ✆ ✄ ✔ ✕ ✟✒ ✘ ✄ ✄ ✕ ✌ ✙ ✄ ✌ ☛ ✆ ✎ ✄ ✡ ✎ ✌ ✄ ✔ ✒ ✄ ✌ ✡ ✄ ✆ ✄ ✒ ✞ ✆ ☛ ☛ ✂ ✕ ☛ ✕ ✆ ✄ ✄ ✔ ✒ ✆ ✄ ✡ ✡ ✄ ✓ ✎ ✌ ☎ ✆ ✝ ✗ ✄ ✏ ✞ ✟✄ ✡ ✠ ✗ ✡ ✏ ✆ ✎ ✗ ✄ ✆ ✡ ☛ ✞ ☛ ✂ ✄ ✄ ✔ ✏ ✂ ✕ ✌ ✖✄ ✆ ✕ ☛ ✄

Exchange Rate $Cdn cost of hotel (1) subscribe (2) publish

Subscriber Publisher

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁✒ ✁

Implementing Design Patterns

• Design patterns represents strategies for
• rganizing code, not explicit implementations
• Actual implementation used must be

determined on a case-by-case basis

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Event-Connector Implementation

✥ ✦ ✧ ✩ ✪ ✫ ✧ ✫ ✧ ✬ ✧ ✭ ✧ ✫ ✮ ✯ ✱ ✧ ✲ ✳ ✴ ✵ ✶ ✫ ✸ ✧ ✹ ✶ ✮ ✧ ✺ ✵ ✶ ✫ ✸ ✧ ✻ ✲ ✭ ✧ ✫ ✮ ✼ ✧ ✱ ✼ ✧ ✽ ✧ ✫ ✮ ✪ ✫ ✸ ✴ ✵ ✶ ✫ ✸ ✧ ✪ ✫ ✧ ✳ ✴ ✵ ✶ ✫ ✸ ✧ ✼ ✶ ✮ ✧ ✥ ✺ ✾ ✫ ✫ ✧ ✴ ✮ ✽ ✿ ❀ ✽ ✴ ✼ ✪ ❀ ✧ ✼ ✽ ✮ ✾ ✱ ✿ ❀❁ ✪ ✽ ✵ ✧ ✼ ✭ ✪ ✶ ✧ ✭ ✧ ✫ ✮ ✴✾ ✫ ✫ ✧ ✴ ✮ ✾ ✼ ❂ ❃ ❄ ❅ ❆❇ ❈ ❉ ❅ ❊ ❈ ❆ ❇ ❋

• ❇

❍■ ■ ❊ ❇ ❏ ❑ ❆ ▲ ❋ ❈ ▼ ❊ ❏ ❏ ❍ ❇ ❍■ ■ ❊ ❇ ❏ ◆ ❖ P ◗❘ ❙ ❚ ❯ ❱ ❯ ❲ ❳❨ ❩ ❚ ◗ ❬ ❪ ❙ ❫ ❙ ❳❨ ❴ ❵ ❱ ❯ ❲ ❳❨ ❩ ❛ ❲ ❜ ❩ ❝ ❯ ❲ ❳❨ ❩ ❞ ❴ ❡ ❩ ❳ ❜ ❩ ❡ ❩ ❳ ❜ ❚

Exchange Rate $Cdn cost of hotel (1) subscribe = connectAsTarget (2) publish = raiseEvent

Subscriber Publisher

SLIDE 5

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Code for Target (Subscriber) Interface

// Target implements this method. It is called by the // event connector whenever a new event is fired. public interface EventTarget { public void performEvent (EventObject e); }

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Code for New Event Type

import java.util.EventObject; public class ExchangeRateChangedEvent extends EventObject { private float newExchangeRate; public int getNewExchangeRate () { return newExchangeRate; } public ExchangeRateChangedEvent ( Object source, float newRate) { super (source); newExchangeRate = newRate; } }

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

EventConnector (Publisher) Code

public class EventConnector { //There are zero or more targets represented as a vector private Vector targets = new Vector(); // When a new event is raised, the "performEvent" method of // each target is invoked public void raiseEvent (EventObject e) { for (int i=0; i<targets.size(); i++) { EventTarget t = (EventTarget) targets.elementAt (i); t.performEvent (e); } } //Each target must register itself as a target of this //connector. public void connectAsTarget (EventTarget targetComponent) { targets.add(targetComponent); } }

✓ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

More on Publish/Subscribe

• Basis of the Event-based Architectural Style
• Greatly improves modifiability and

extendibility of systems

– At the expense of interaction complexity – which may make analysis more difficult

• Used in most (all) graphical user interface

frameworks

• Also very popular in development

environments (e.g. IBM Eclipse) where a variety of tools can be easily integrated

SLIDE 6

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Sequence Diagram

Publisher Subscriber1 Subscriber2

connectAsTarget connectAsTarget raiseEvent (change in state initiated by outside source or Publisher) performEvent performEvent

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Where do Design Patterns Come From?

• Actually mined from code

– General rule -- design pattern must be seen in at least three real systems before it is considered to be a design pattern

• ✒

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Reading

• Bahrami mentions design patterns, no details
• Supplementary text for this topic:
• ✁

✂ ☎ ✆ ✞ ✟ ✠ ✡ ✡✠ ☛ ✌☎ ✆ ✞ ✠ ✂ ✍ ✎ ✏ ✑ ✡ ☛ ✌ ✠ ✑ ✒ ✞ ✔ ✕ ✞ ✖ ✗ ✕ ✖ ✠ ✖ ✍ ✔ ✕ ✞ ✖ ✘ ✑ ☎ ✗ ✗ ☎ ✍ ✏ ✗ ☛ ✙ ✚ ✛ ✜ ✢ ✣ ✤ ✥ ✦ ✦ ✚ ✧ ✣ ✛ ★ ✩ ✪ ✚ ✫ ✚ ✣ ✦ ✛✬ ✭ ✮ ✚ ✯ ✛ ✥ ✰ ✪ ✚ ✱ ✰ ✲ ✚✳ ✦ ✴ ✱ ✧ ✜ ✚ ✣ ✦ ✚ ✶

• ✕

✖ ✂ ✏ ✗ ✏ ✂✷ ✏ ☎ ✖ ✸ ✕ ✹ ✺ ✑ ✠ ✗ ✻ ☎ ✼ ✂ ✠ ✂✽

• pages for each design pattern listed on web & slides
• pages for publish/subscribe pattern: 293-303
• ✾

✆ ✠ ✑ ✑ ✏ ✍ ✿ ✞ ✏ ❀ ❁ ✼ ✗ ✏ ✂✷ ✏ ✂ ❀ ✒ ✠ ✿ ✿ ✏ ✂ ✖ ❂

• note: this text uses C++/Smalltalk, UML-like notation
• ✖

✕ ✿ ✞ ✠ ✂ ✍ ✿ ✕ ❃ ✕ ✑ ✑ ✕ ❄❅ ✍ ✕ ✖ ❆ ✿ ✺ ✏ ✿ ✞ ✹ ✖ ✺ ✹ ✒ ✕ ✖ ✍ ✏ ✿ ✠ ☎ ✑ ✗

CISC 323 Intro to Software Engineering

Lecture 6-2 Adapter, Façade, Abstract Factory, and Flyweight Design Patterns

SLIDE 7

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Adapter Design Pattern [Gamma et al., pp 139-150]

• Motivation

– Sometimes a class implements functionality similar to what an application requires, but not the correct interface for that application – E.g. We wish to implement a BookList class implementing a list of text book used in a course

int getNumBooks() Book getBook (int n) void addBook (Book newBook)

– These operations are very similar to the

• perations in the predefined Vector class
• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Adapter Design Pattern

• Options:

– Implement BookList from scratch

✁ ✂ ✄ ✆✝ ✞✟ ✠ ✡ ✝ ☛ ✝ ☞ ☞ ✌ ☞ ✆ ☞ ✌ ✞ ✝

– Use Vector

✁ ✍ ✌ ✞ ✎ ✏ ✑ ✝ ✏ ✒ ✝ ✟ ✠ ☞ ✝ ✒ ✠ ✞ ✏ ✝ ☞ ✓ ✔ ✖ ✝ ✓ ✌ ☞ ✗ ✌ ✌ ✘ ✙ ✠ ✟ ✏

– Adapt Vector to BookList interface

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Adapter

• Two ways of adapting the Vector

– Class adapter

✁ ✗ ✔ ✟ ✝ ✒ ✌ ✞ ✠ ✞ ✤ ✝ ☞ ✠ ✏ ✔ ✞ ✖ ✝

– Object adapter

✁ ✗ ✔ ✟ ✝ ✒ ✌ ✞ ✔ ✑ ✑ ☞ ✝ ✑ ✔ ✏ ✠ ✌ ✞

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Class Adapter

SLIDE 8

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒

• ✒

✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• ✒

Class Adapter

public interface BookList { public int getNumBooks(); public Book getBook(int n); public void addBook(Book newBook); }

BookList.java

import java.util.Vector; public class BookListClassAdapter extends Vector implements BookList { public int getNumBooks() { return size(); } public Book getBook(int n) { return (Book) elementAt(n); } public void addBook(Book newBook) { for (int i=0; i<getNumBooks(); i++) { Book b=getBook(i); if (b.isSameBook (newBook)) { b.setQuantity (b.getQuantity() + newBook.getQuantity()); return; } } add (newBook); } }

BookListClassAdapter.java

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✒

• ✓

☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• // This code simply shows how a book list is instantiated

public class SampleClient { public static void main (String [] args) { Book b = new Book (…); BookList bl = new BookListClassAdapter (); bl.addBook (b); System.out.println (“Book list has ” + bl.getNumBooks() + “ books”); } }

SampleClient.java

✒ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✒

• ✓

☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• Class Adapter
• Adapter simply inherits operations of Vector
• Clients use BookList interface, not

BookListClassAdapter directly

• ✁

✂ ✄ ✆ ✄ ✝ ✞ ✆ ✄ ✂ ✟ ✠ ✄ ✡ ☛ ☞ ✌✍ ✟ ✎ ✑✄ ✒ ✂ ✞ ✠ ✡ ✞ ✝ ✓ ✔✕ ✖ ✗ ✙ ✚ ✛ ✢✣ ✤ ✥ ✦ ✧ ★ ✩

SLIDE 9

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍ ✑

• ✒

☛ ☛ ✓ ✔ ✕ ✕ ✖ ✖ ✗ ✙ ✝ ✗ ✚ ✂ ✄ ✄☎ ✝ ✂ ✗ ✙✛ ✕ ✜ ✙ ✟ ✝ ✙ ✑

• General Form of Class Adapter
• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍ ✑

• ✒

☛ ☛ ✓ ✔ ✕ ✕ ✖ ✖ ✗ ✙ ✝ ✗ ✚ ✂ ✄ ✄☎ ✝ ✂ ✗ ✙✛ ✕ ✜ ✙ ✟ ✝ ✙ ✑

• Object Adapter

Object Adapter

import java.util.Vector; public class BookListObjectAdapter implements BookList { private Vector books = new Vector(); public int getNumBooks() { return books.size(); } public Book getBook(int n) { return (Book) books.elementAt(n); } public void addBook(Book newBook) { for (int i=0; i<getNumBooks(); i++) { Book b=getBook(i); if (b.isSameBook (newBook)) { b.setQuantity (b.getQuantity() + newBook.getQuantity()); return; } } books.add (newBook); } }

BookListObjectAdapter.java

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍ ✑

• ✒

☛ ☛ ✓ ✔ ✕ ✕ ✖ ✖ ✗ ✙ ✝ ✗ ✚ ✂ ✄ ✄☎ ✝ ✂ ✗ ✙✛ ✕ ✜ ✙ ✟ ✝ ✙ ✑

• // This code simply shows how a book list is instantiated

public class SampleClient { public static void main (String [] args) { Book b = new Book (…); BookList bl = new BookListObjectAdapter (); bl.addBook (b); System.out.println (“Book list has ” + bl.getNumBooks() + “ books”); } }

SampleClient.java

SLIDE 10

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍ ✑

• ✒

☛ ☛ ✓ ✔ ✕ ✕ ✖ ✖ ✗ ✙ ✝ ✗ ✚ ✂ ✄ ✄☎ ✝ ✂ ✗ ✙✛ ✕ ✜ ✙ ✟ ✝ ✙ ✑

• General Form of Object Adapter
• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍ ✑

• ✒

☛ ☛ ✓ ✔ ✕ ✕ ✖ ✖ ✗ ✙ ✝ ✗ ✚ ✂ ✄ ✄☎ ✝ ✂ ✗ ✙✛ ✕ ✜ ✙ ✟ ✝ ✙ ✑

• Relation to Quality Attributes
• Modifiability

– Adapter class provides clean interface to clients of adapted object

• Reusability

– Takes advantage of adapted class for reuse

• Correctness

– Takes advantage of tested code

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✒

• ✓

☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• The Façade Pattern

[Gamma et al., pp 185-193]

• Motivation

– Sometimes part of a system is itself implemented as a subsystem, consisting of a set of objects – Rather than revealing subsystem structure to rest

• f system, use façade object to provide interface

to subsystem as a whole

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✒

• ✓

☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• General Idea

client classes subsystem classes Facade

SLIDE 11

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✒

• ✓

☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒

• The Façade Pattern
• Example

– A student information system provides access to functions on

✁ ✂ ✄ ☎ ✝ ✞ ✝ ✠ ☛ ☞✌ ✝ ✞ ☎ ✍ ☞ ☞✌ ✍ ✎ ✏ ☞ ☛ ✑ ✌ ☎ ✒ ✑ ✓ ☞✌ ✕ ✎ ✠ ✍ ✞ ☞ ✖ ✂ ✄ ☎ ✝ ✕ ✎ ✠ ✍ ✞ ☞ ✞ ☎ ✒ ✑ ✓ ☞✌ ✞ ✝ ✠ ☛ ☞✌ ✝ ✑ ✞ ☞✌ ✍ ✎ ✏ ☞ ☛ ✑ ✌ ✖ ✂ ✄ ☞ ✍ ☞ ☎ ✒ ✑ ✓ ☞✌ ✕ ✎ ✠ ✍ ✞ ☞ ✑ ✞ ✗ ☞ ✑ ✌ ✒ ✄ ☞ ✏ ☛

– Implemented via three classes

✖ ✘ ✎ ✠ ✍ ✞ ☞ ✞ ✙ ✑ ✌ ✚ ✎ ✍ ✛☎ ✝ ✑ ✎ ✌ ✎ ✌ ✕ ✎ ✠ ✍ ✞ ☞ ☞✌ ✍ ✎ ✏ ✏ ✛☞✌ ✝ ✞ ✖ ✜ ✝ ✠ ☛ ☞✌ ✝ ✞ ✙ ✑ ✌ ✚ ✎ ✍ ✛☎ ✝ ✑ ✎ ✌ ✎ ✌ ✞ ✝ ✠ ☛ ☞✌ ✝ ✞ ✢ ✕ ✎ ✠ ✍ ✞ ☞ ✞ ✖ ✣ ☎ ✕ ✑ ✏ ✑ ✝ ✑ ☞ ✞ ✙ ✑ ✌ ✚ ✎ ✍ ✛☎ ✝ ✑ ✎ ✌ ✎ ✌ ✏ ✎ ✕ ☎ ✝ ✑ ✎ ✌ ✎ ✚ ✕ ✎ ✠ ✍ ✞ ☞ ✞

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Student Information System Classes

class Courses { … public StudentList getEnrollment (CourseId c) { … } … } class Students { … public CourseList getCourses (StudentId s) { … } } class Facilities { … public LectureHallId getLectureHall (CourseId c) { … } }

Courses.java Students.java Facilities.java

• ✒

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Student Information System without Façade

Student Information Subsystem

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Student Information System with Façade

Student Information Subsystem

SLIDE 12

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Façade Implementation

public class StudentInformation System { Courses cs; Students ss; Facilities fs; … public StudentList getEnrollment (CourseId c) { return cs.getEnrollment (c); } public CourseList getCourses (StudentId s) { return ss.getCourses (s); } public LectureHallId getLectureHall (CourseId c) { return fs.getLectureHall (c); } }

StudentInformationSystem.java

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Relation to Quality Attributes

• Modifiability

– By removing external links to subsystem components, impact of changes to subsystem components limited to subsystem itself

• Performance

– Slight performance cost of extra call indirection through façade

✁ ✂ ✄ ✆ ✝ ✞✟ ✠ ✡ ✆ ✡ ✄ ☛ ✆ ☞ ✟ ✌ ✞ ✍ ✞ ✆ ✌ ✟ ✞ ✞ ✄ ✎ ✏ ✠ ✞ ✑ ✠ ✒ ✠ ✞✓ ✔ ✆ ✕ ✓ ✆ ✖ ✗ ✓ ✆ ✟ ✠ ✍ ✄ ☛ ✡ ✓ ✘ ✘✙ ✓ ✗ ✆ ☞ ✟ ☞ ✚ ✌ ✠ ✛ ✠ ✍ ✜ ✆ ✏ ✌ ✞ ✌ ✌ ✢ ✆ ✡ ✠ ✎ ✠ ✘ ✘ ✞ ✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Another Example: SavitchIn

• Input with Java API:

✥ ✦ ✧ ✩ ✪ ✫ ✩ ✬✭ ✮ ✭ ✬ ✪ ✯ ✭ ✬ ✩ ✬ ✰ ✱ ✫ ✲ ✫ ✱ ✭ ✭ ✬✭ ✥ ✩ ✬ ✰ ✳ ✴ ✬ ✧ ✬ ✰ ✱ ✫ ✵ ✯ ✫ ✬ ✶ ✦ ✷ ✫ ✬ ✸ ✹ ✺✻ ✼ ✽ ✾ ✻ ✿❀ ✽ ❁ ❂ ❃ ✾ ❄ ❅ ❁ ✻ ✽ ✿ ❆ ❀ ❈ ❉ ✾ ❁ ✼ ✿ ❈ ❊ ❃ ❆ ❁ ✽ ❁ ❋

• ✾

✽ ❊ ❋ ✽ ✾ ✻ ❂ ✹ ✺✻ ✼ ✽ ✾ ✻ ✿ ❋ ✾ ❍ ❋ ❁ ✽ ❅ ❈ ✼ ✻ ✽ ❄ ✿ ✻ ❋ ✻ ✹ ✼ ❁ ❋ ❈ ❀ ❈ ✾ ❊ ■ ❊ ✾ ✽ ❊ ❁ ❀ ✿ ❈ ❀ ❀ ✾ ✽ ✾ ✼ ❋ ❃ ❈ ✼ ✿ ❊ ❁ ❀ ✾ ✽ ✽ ❁ ✽ ❊ ✥ ✱ ✧ ✮ ✦ ✭ ✱ ✧ ✲ ✬ ✦ ✯ ✳ ✪ ✮ ❏ ✮ ✭ ❑ ▲ ✱ ✧ ❑ ✭ ✦ ▼ ◆ ✫ ✬ ❖ ✬ ✳ ✷ ✪ ✱ ✰ P ✦ ✧ ◆ ✮ ❑

• SavitchIn:

✥ ✰ ✬ ✱ P ✭ ❑ ✬ ✶ ❑ ✯ ✰ ✪ ▼ ❖ ✬ ✳ ✷ ✪ ✱ ✰ P ✥ ✰ ✬ ◗ ◆ ✰ ✪ ▼ ◆ ❑ ✭ ✪ ✰ ✱ ✷ ✪ ✰ ❑ ✭ ✦ ✧ ✲ ✱ ✭ ✬ ✪ ✰ ✬ ✰ ✰ ✪ ✰ ✭ ✥ ✩ ✬ ✰ ✳ ✬ ✱ ✭ ✳ ❑ ✪ ✮ ✭ ✬ ✯ ✪ ✰ ❑ ❙ ✦ ✭ ◆ ✮ ✰ ◆ ✪✭ ✬ ✥ ✧ ✪ ❑ ✯ ✫ ✬ ✶ ✦ ✷ ✫ ✬ ✸ ▼ ✱ ✧ ✳ ✯ ✬ ✱ ❑ ✮ ✰ ✬✭ ✧ ✪ ❑ ✦ ✧ ✲ ✫ ✮ P ✬ P

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Categories of Patterns

• The patterns we have seen so far address

structural problems in programs

– Adapter -- structures programs to aid reuse – Façade -- localizes references to a subsystem, aiding modifiability

• Also interesting are

– Creational patterns -- help in object creation – Behavioural patterns -- help manage runtime behaviour of program

✥ ✦ ✧ ★✩ ✪ ✫ ✬✭ ✫ ✧ ★ ✫✮ ✯ ✪ ★ ✰ ✪ ✫ ✲✳ ✰ ✰ ✴ ✵ ✶ ✦ ✩ ✰

SLIDE 13

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Abstract Factory

[Gamma et al., pp. 87-95]

• Motivation

– Imagine you have a book ordering system in which you need to maintain a list of books

✥ ✦ ✧ ✧ ✩ ✪ ✫ ✬ ✭ ✮ ✬ ✫ ✫ ✭✧ ✯ ✰ ✬ ✪ ✯ ✪ ✯✱ ✬ ✰ ✪ ✰ ✮ ✲ ✴ ✬ ✵ ✰ ✶ ✧ ✷ ✴ ✸ ✹ ✦ ✺ ✴ ✻ ✥ ✼✦ ✧ ✧ ✩ ✽ ✪ ✫ ✰ ✪ ✫ ✬ ✮ ✪ ✫ ✰ ✧ ✾✿ ✧ ✧ ✩ ✫ ✴ ✪ ✯ ✭ ✮ ✵ ❀ ✪ ✯✱ ✬ ❁ ✵ ✬ ✯ ✰ ✪ ✰ ❂ ❄ ❅ ❇ ✾ ✧ ✷ ✲ ✬ ✭ ✶ ✿ ✧ ✧ ✩

– Initially, you wish to maintain a simple Vector – However, after the system has been delivered, you decide you want a data structure that also permits books to be represented in sorted order

import java.util.Vector; public class BookListClassAdapter extends Vector implements BookList { public int getNumBooks() { return size(); } public Book getBook(int n) { return (Book) elementAt(n); } public void addBook(Book newBook) { for (int i=0; i<getNumBooks(); i++) { Book b=getBook(i); if (b.isSameBook (newBook)) { b.setQuantity (b.getQuantity() + newBook.getQuantity()); return; } } add (newBook); } }

Here is an initial implementation of a BookList

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Abstract Factory

• Adding sorting behavior to the BookList class

– Option 1: Modify BookList so that every time a book is entered, the Vector is sorted

✥ ✦ ✧ ★✩ ✪ ✫ ✬ ✮✯ ✰ ✱ ✲ ✳✴ ✮ ✵ ✯ ✶✷ ✳ ✸ ✬ ✹ ✬ ✬ ✺ ✫ ✱ ✴ ✸ ✮ ✰ ✯ ✴ ✴ ✱ ✸ ✴ ✳ ✰✻ ✥ ✼ ★✽ ✩ ✪ ✾ ✬ ✿❀ ✮ ✳ ✸ ✬ ✹ ✬ ✬ ✺ ✫ ✱ ✴ ✸ ❁ ✯ ❂ ✶ ✬ ✸ ❃ ✳ ✯ ❄ ✯ ✱ ✰ ✯ ❃ ✰ ✳ ✪ ✹ ✬ ✬ ✺ ✫ ✱ ✴ ✸ ❁ ✯ ❂ ❃ ✳ ✿ ✴ ✳ ❅ ✱ ✶ ✬ ✸ ✵ ✳ ❀ ❆ ❀ ✬ ✷ ❀ ✯ ❁✴ ❇ ✬ ✸ ✵ ✳ ❀ ✴ ✿ ❃ ✴ ❂ ✴ ✸ ✳ ❁ ✴ ✬ ✻ ✴ ✯ ❁ ✳ ❆ ❀ ✬ ✷ ❀ ✯ ❁ ❇ ✴ ✬ ✸ ✵ ✯ ✸ ✮ ✵ ✯ ✶✷ ✳ ✱ ✶ ✮ ✰ ✯ ✴ ✴ ✻ ✿ ✶ ✮ ✸ ✱ ✬ ✶ ✯ ✰ ✱ ✸ ❂ ✮ ✬ ✿ ✰ ❅ ✵ ✯ ❄ ✳ ❉ ✱ ❅ ✳ ❀ ✱ ❁ ❆ ✯ ✮ ✸ ✸ ✵ ✯ ✶ ❆ ✰ ✯ ✶ ✶ ✳ ❅ ✪ ❊ ✯ ✶✷ ✳ ❀ ✬ ✻ ❄ ✳ ❀ ✴ ✱ ✬ ✶ ❆ ❀ ✬ ✰ ✱ ✻ ✳ ❀ ✯ ✸ ✱ ✬ ✶ ❇ ❉ ✵ ✳ ❀ ✳ ❅ ✱ ✻ ✻ ✳ ❀ ✳ ✶ ✸ ❄ ✳ ❀ ✴ ✱ ✬ ✶ ✴ ✬ ✻ ✹ ✬ ✬ ✺ ✫ ✱ ✴ ✸ ❉ ✱ ✸ ✵ ❅ ✱ ✻ ✻ ✳ ❀ ✳ ✶ ✸ ✻ ✿ ✶ ✮ ✸ ✱ ✬ ✶ ✯ ✰ ✱ ✸ ❂ ✯ ❆ ❆ ✳ ✯ ❀ ✱ ✶ ❅ ✱ ✻ ✻ ✳ ❀ ✳ ✶ ✸ ❆ ❀ ✬ ✷ ❀ ✯ ❁ ✴ ❋ ❋ ✱ ✶ ✮ ❀ ✳ ✯ ✴ ✳ ✴ ❆ ❀ ✬ ❃ ✰ ✳ ❁ ✴ ❉ ✱ ✸ ✵ ❁ ✯ ✱ ✶ ✸ ✳ ✶ ✯ ✶ ✮ ✳

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Abstract Factory

• Option 2:

– Create a BookList interface with the required functionality of maintaining a list of books – Create an abstract factory class that creates an instance of the correct kind of BookList

SLIDE 14

• ✒

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

BookList variants

• ✁

✂ ✂ ☎ ✆✝ ✞ ✟ ✠ ✡ ☛ ☞ ✍ ✎ ✏ ✒ ☞ ✓✔ ☞ ✒ ✠ ✎ ✠ ☞ ✓ ☛ ✕ ☞ ✍ ☞ ✖ ✗ ✠ ✍ ☞ ✘ ✙✔ ☞ ✍ ✏ ☛ ✠ ✙ ✡ ✓ ✎ ✙ ✍ ✏ ✚ ✠ ✓ ☛ ✙ ✎✛ ✙ ✙ ✜ ✓ ✢ ✣ ✤ ✥ ✟ ✂ ✦ ✁ ✂ ✂ ☎ ✆ ✝ ✞ ✟ ✠ ✓ ☛ ✕ ☞ ✓ ✠ ✧ ✔ ✚ ☞ ★ ☞ ✒ ☛ ✙ ✍ ✠ ✧ ✔ ✚ ☞ ✧ ☞ ✡ ☛ ✏ ☛ ✠ ✙ ✡ ✢ ✩ ✂ ✦ ✟ ✝ ✪✫ ✣ ✤ ✥ ✟ ✂ ✦ ✁ ✂ ✂ ☎ ✆✝ ✞ ✟ ✏ ✘ ✘ ✓ ✓ ✙ ✍ ☛ ✠ ✡ ✬ ✎ ✗ ✡ ✒ ☛ ✠ ✙ ✡ ✏ ✚ ✠ ☛ ✭ ✢ ✯ ✣ ✆ ✰ ✦ ✤ ✤ ✁ ✂ ✂ ☎ ✆✝ ✞ ✟ ✔ ✍ ✙ ★ ✠ ✘ ☞ ✓ ✎ ✏ ✓ ☛ ☞ ✍ ✚ ✙ ✙ ✜ ✗ ✔✓ ✱ ✓ ✙ ✍ ☛ ✠ ✡ ✬ ✓ ✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Problems with Changing Implementations

• Problem: If we change from the

VectorBookList to SortingVectorBookList implementation, need to ensure that wherever we create a book list, we replace “new VectorBookList()” with “new SortingVectorBookList()”

• This could be a large change

– What if source to classes creating book lists is not available?

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Abstract Factory

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Abstract Factory

✁ ✂ ✄ ☎✝ ☎ ✞ ☎ ✟ ✠✡ ☛ ☞ ☎✝ ✌ ✍ ✎ ✏ ☎ ✡ ✌ ✑ ☞ ✓ ✄ ☎ ✓ ✌ ✍ ✡ ✟ ☎ ✠ ✌ ☎ ✠ ✝ ☞ ✝ ✓ ✌ ✠ ✝ ✡ ☎ ✍ ✕ ✠ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ✢ ☞ ✌ ✡ ✠ ☛ ☛ ✓ ✌ ✄ ☎ ✤ ✥ ✦✧ ✜ ✦ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ★✩ ✪ ☎ ✌ ✄ ✍ ✫ ✍ ✕ ✌ ✄ ☎ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ✬ ✧ ✤ ✜ ✗ ✥✭ ✁ ✮ ✄ ☞ ✓ ☞ ✓ ✠ ✝ ✍ ✎ ✏ ☎ ✡ ✌ ✌ ✄ ✠ ✌ ✟ ☎ ✌ ✯ ✟ ✝ ✓ ✠ ✞ ✠ ☛ ✯ ☎ ✍ ✕ ✌ ✰ ✱ ☎ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ✁ ✮ ✄ ☎ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ✬ ✧ ✤ ✜ ✗ ✥✭ ☞ ✓ ✓ ✱ ☎ ✡ ☞ ✠ ☛ ☞ ✲ ☎ ✫ ✌ ✍ ✠ ✕ ✠ ✡ ✌ ✍ ✟ ✰ ✡ ✠ ✱ ✠ ✎ ☛ ☎ ✍ ✕ ✟ ☎ ✌ ✯ ✟ ✝ ☞ ✝ ✴ ✌ ✄ ☎ ✡ ✍ ✟ ✟ ☎ ✡ ✌ ✵ ☞ ✝ ✫ ✍ ✕ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ✁ ✶ ☎ ✟ ☎ ✢ ✠ ✷ ✦ ✤ ✜ ✗ ✥ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜ ✬ ✧ ✤ ✜ ✗ ✥✭ ✡ ✟ ☎ ✠ ✌ ☎ ✓ ☞ ✝ ✓ ✌ ✠ ✝ ✡ ☎ ✓ ✍ ✕ ✷ ✦ ✤ ✜ ✗ ✥ ✖ ✗ ✗ ✘ ✙✚ ✛ ✜

SLIDE 15

BookListFactory

public interface BookListFactory { public BookList createBookList (); } class VectorBookListFactory implements BookListFactory { public BookList createBookList () { return new VectorBookList (); } } class Client { … BookListFactory blf; … BookList b = blf.createBookList(); }

BookListFactory.java VectorBookListFactory.java Client.java

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Extending to Multiple Factories

The client is provided with an object of type

• BookList. This object may be either a

VectorBookList or a SortingVectorBookList, depending on which factory was used.

BookListFactory Client uses VectorBookListFactory SortingVectorBookListFactory <<interface>> BookList uses VectorBookList SortingVectorBookList creates creates

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Extending to Multiple Factories

The client is provided with an object of type

• BookList. This object may be either a

VectorBookList or a SortingVectorBookList, depending on which factory was used.

BookListFactory Client uses VectorBookListFactory SortingVectorBookListFactory <<interface>> BookList uses VectorBookList SortingVectorBookList creates creates

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Extending to Multiple Factories

The client sees an object of type BookListFactory, so does not need to know whether it is using a VectorBookListFactory

• r a SortingVectorBookListFactory

BookListFactory Client uses VectorBookListFactory SortingVectorBookListFactory <<interface>> BookList uses VectorBookList SortingVectorBookList creates creates

SLIDE 16

General Form of Abstract Factory

• ✓

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Relating to Quality Attributes

• Modifiability

– Increased through use of indirection in creation process – Creator does not need to know exactly what type

• f object is being created

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁ ✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁ ✒ ✁

The Flyweight Pattern

[Gamma et al., pp 195-206]

• Sometimes objects too expensive for

applications where large numbers of objects required

• Flyweight objects provide cheaper object

mechanism

• Illustrates abstract factory pattern
• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁ ✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁ ✒ ✁

Flyweight

• In a text editor, wish to

represent a set of rows, and within each row a set of columns

• Each row in turn contains a

set of characters

• Logically, each character is

an object

• However, a document of

tens of thousands of characters would require tens of thousands of objects

a p p a r e n t

SLIDE 17

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁ ✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁ ✒ ✁

Flyweight

✁ ✂ ✄☎ ✆ ✝ ✟ ✠ ✡ ☞ ✌ ✝ ✟ ✆ ✝ ✍ ✄ ✝ ✍ ✎ ✏ ✝ ☞ ✆ ✑ ✝ ✌ ☞ ✒ ✟ ✌ ✟ ☞ ✆ ✝ ✌ ✓ ✔ ✟ ☞ ✒ ✍ ✕ ✆ ✒ ✝ ☎ ✝ ✖ ☎ ☞ ✟ ✗ ✗ ✝ ✠ ✟ ✕✗ ✘ ✚ ✝ ✖ ✛ ✒ ✆ ✍ ✎ ✏ ✝ ☞ ✆ ✓ ✢ ✗ ✘ ✚ ✝ ✖ ✛ ✒ ✆ ✍ ✎ ✏ ✝ ☞ ✆ ☎ ☞ ✟ ✄ ☞ ✍ ✄ ✆ ✟ ✖ ✄ ✍ ✄ ✗ ✘ ✠ ✟ ✆ ✟ ☎ ✒ ✟ ✌ ✝ ✠ ✟✣ ✍ ✄ ✛ ☎ ✆ ✟ ✗ ✗ ✖ ✄☎ ✆ ✟ ✄ ☞ ✝ ☎ ✍ ✕ ✍ ✎ ✏ ✝ ☞ ✆ ☎ ✤ ✥ ✦ ★ ✦✩ ✪ ✫ ✬ ✮ ✬ ✪ ✯ ✰ ✮ ✱✬ ✲ ✰ ✩ ✳ ✴ ✯ ✱✶ ✯ ✷ ✶ ✸ ✹ ✯ ✹ ✶ ✱ ✩ ✻ ✶ ✱ ✯ ✓ ✔ ✼ ✆ ✌ ✖ ✄☎ ✖ ☞ ☎ ✆ ✟ ✆ ✝ ✣ ✽ ☎ ✆ ✎ ✝ ✑ ✟☎ ☎ ✝ ✠ ✟☎ ✟ ✑ ✟ ✌ ✟✣ ✝ ✆ ✝ ✌ ✆ ✍ ✍ ✑ ✝ ✌ ✟ ✆ ✖ ✍ ✄☎ ✍ ✄ ✕✗ ✘ ✚ ✝ ✖ ✛ ✒ ✆

a p p a r e n t a b c d e f g h i k l m n

• p

q r s t u v w x y z

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Flyweight

• Intrinsic state: data that

can be shared by many instances of object

✤ ✥ ✦ ★ ✦✩ ✪ ✫ ✬ ✮ ✬ ✪ ✯ ✰ ✮ ✲✬ ✳ ✰ ✩ ✴ ✵ ✯ ✲✷ ✯ ✸ ✷ ✹ ✺ ✯ ✺ ✷ ✲ ✩ ✻ ✷ ✲ ✯

• Extrinsic state: specific

to a particular instance

✤ ✥ ✦ ★ ✦✩ ✸ ✷ ✹ ✺ ✯ ✺ ✷ ✲ ✩ ✻ ✷ ✲ ✯

a p p a r e n t a b c d e f g h i k l m n

• p

q r s t u v w x y z

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Flyweight Implementation

create (intrinsicData)

• Client creates flyweight instances using flyweightFactory
• Factory requires intrinsic data as parameter -- e.g., parameter is

“a” to create instance of character “a”

• Factory returns flyweight object with this intrinsic data
• Client must maintain extrinsic data -- e.g., character font, position
• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Relation to Quality Attributes

• Performance

– Systems with tens/hundreds of thousands or more

• f objects can be prohibitively expensive in

memory use – Flyweight objects reduce this expense

• Modifiability

– Encapsulation of system functionality no longer as clear – Separation of intrinsic/extrinsic state into different

• bjects

SLIDE 18

CISC 323 Intro to Software Engineering

Lecture 6-3 Composite, Iterator, and Builder Design Patterns

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Composite Design Pattern

[Gamma et. al. pp.163-173]

• Intent

– To compose object into tree structures that represent part-whole hierarchies – Lets clients treat individual objects and compositions of objects uniformly

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Motivation

• Problem:

✁ ✂ ✄ ☎ ✆✝ ✞✟ ✠✡ ☛ ✆ ☞ ✌ ☎ ✍ ✏ ✞ ☎ ✏ ✍ ✆ ✌✑ ✍ ✆ ✒ ✏ ✓ ☛ ☎ ✟ ✏ ☎ ✟ ✄ ✌ ✓ ✠✡ ☛ ✆ ✞ ✟ ✠✡ ✟ ✝ ✆✝ ☎ ✌ ✔ ✕ ✟ ✖ ✆ ☎ ✗ ✑ ☎ ✏ ✌ ✆ ✌ ☎ ✗ ✆ ✌ ✆ ✌ ☎ ✍ ✏ ✞ ☎ ✏ ✍ ✆ ✌ ✠ ✏ ✌ ☎ ✍ ✆ ✑ ☎ ✡ ✍ ✓ ✠ ✓ ☎ ✓ ✘ ✆ ✟ ✒ ✚ ✆ ✞ ☎ ✌ ✑ ✝ ✖ ✞ ✟ ✝ ☎ ✑ ✓ ✝ ✆ ✍ ✟ ✒ ✚ ✆ ✞ ☎ ✌ ✖ ✓ ✄ ✄ ✆ ✍ ✆✝ ☎ ☛ ✛ ✆ ✘ ✆✝ ✓ ✄ ✠ ✟ ✌ ☎ ✟ ✄ ☎ ✗ ✆ ☎ ✓ ✠ ✆ ☎ ✗ ✆ ✏ ✌ ✆ ✍ ☎ ✍ ✆ ✑ ☎ ✌ ☎ ✗ ✆ ✠ ✓ ✖ ✆✝ ☎ ✓ ✞ ✑ ☛ ✛

• Solution: Use the composite design pattern

✔ ✢ ✝ ✑ ✒ ✌ ☎ ✍ ✑ ✞ ☎ ✞ ☛ ✑ ✌ ✌ ☎ ✗ ✑ ☎ ✍ ✆ ✡ ✍ ✆ ✌ ✆✝ ☎ ✌ ✒ ✟ ☎ ✗ ✡ ✍ ✓ ✠ ✓ ☎ ✓ ✘ ✆ ✌✑ ✝ ✖ ✞ ✟ ✝ ☎ ✑ ✓ ✝ ✆ ✍ ✌ ✔ ✤ ✗ ✆ ✕ ✟ ✠✡ ✟ ✌ ✓ ☎ ✆ ✡ ✑ ☎ ☎ ✆ ✍ ✝ ✖ ✆ ✌ ✞ ✍ ✓ ✒ ✆ ✌ ✗ ✟ ✥ ☎ ✟ ✏ ✌ ✆ ✍ ✆ ✞ ✏ ✍ ✌ ✓ ✘ ✆ ✞ ✟ ✠✡ ✟ ✌ ✓ ☎ ✓ ✟ ✝ ✌✟ ☎ ✗ ✑ ☎ ☎ ✗ ✆ ✞ ☛ ✓ ✆ ✝ ☎ ✌ ✖ ✟ ✝ ✦ ☎ ✗ ✑ ✘ ✆ ☎ ✟ ✠ ✑ ✧ ✆ ☎ ✗ ✓ ✌ ✖ ✓ ✌ ☎ ✓ ✝ ✞ ☎ ✓ ✟ ✝ ★ ✩ ✪ ✫ ✭ ✭ ✮ ✯ ✰ ✱ ✮ ✲ ✳ ✮ ✴ ✵ ✶ ✪ ✷ ✸ ✱ ✮ ✷ ✴ ✶ ✹

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Applicability

• Use the Composite pattern if…

– You want to represent part-whole hierarchies of

• bjects.

– You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

SLIDE 19

• ✒

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Example: Swing Components

• Component

✁ ✂ ✄ ✆ ✄ ✝ ✞ ✠ ✡ ☛ ☞ ✌ ✞ ✍ ✎ ✏ ✒✓ ✏ ✔✕ ✔ ✖ ✗ ✓ ✘ ✙✚ ✛ ✜ ✢ ✙ ✣ ✖ ✥ ✢ ✜ ✖ ✜ ✚ ✢ ✣ ✣ ✧

• Leaf (atomic components)

★ ✍✩ ✘ ✖ ✖ ✏ ✔ ★ ✍✪ ✢ ✙ ✕ ✚ ★ ✍ ✎ ✫ ✕ ✜ ✬ ✙ ✏ ✭ ★ ✮

• Composite (top-level Swing

containers)

★ ✍✯ ✥ ✢ ✒✕ ★ ✍✰ ✛ ✢ ✚ ✏ ✱ ★ ✮

Given a frame containing multiple panes, each with multiple buttons/labels/checkboxes…

• Call paint() method on frame

causes everything to be painted.

• Changing the look and feel on the

frame is likewise propagated down.

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Participants

• Component

★ ✰ ✕ ✜ ✚ ✢ ✥ ✕ ✣ ✖ ✫ ✕ ✛ ✔ ✖ ✕ ✥ ✥ ✢ ✜ ✕ ✥ ✏ ✥ ✢ ✚ ✚ ✏ ✙ ✦ ✕ ✜ ✖ ✣ ✛ ✔ ✜✏ ✒✓ ✏ ✣ ✛ ✖ ✛ ✏ ✔

• Leaf

★ ✰ ✕ ✥ ✛ ✔✕ ✣ ✙ ✕ ✫ ✢ ✧ ✛ ✏ ✘ ✥ ✥ ✏ ✥ ✓ ✥ ✛ ✒ ✛ ✖ ✛ ✧ ✕ ✏ ✙ ✦ ✕ ✜ ✖ ✣ ✛ ✔ ✜✏ ✒✓ ✏ ✣ ✛ ✖ ✛ ✏ ✔ ★ ★ ✢ ✣ ✔ ✏ ✜ ✫ ✛ ✚ ✩ ✥ ✕ ✔

• Composite

★ ✰ ✕ ✥ ✛ ✔✕ ✣ ✙ ✕ ✫ ✢ ✧ ✛ ✏ ✘ ✥ ✥ ✏ ✥ ✜✏ ✒✓ ✏ ✔✕ ✔ ✖ ✣ ✫ ✢ ✧ ✛ ✔ ✱ ✜ ✫ ✛ ✚ ✩ ✥ ✕ ✔ ★ ✪ ✖ ✏ ✥ ✕ ✣ ✜ ✫ ✛ ✚ ✩ ✜✏ ✒✓ ✏ ✔✕ ✔ ✖ ✣ ★ ✫ ✒✓ ✚ ✕ ✒✕ ✔ ✖ ✣ ✜ ✫ ✛ ✚✩ ✬ ✥ ✕ ✚ ✢ ✖ ✕ ✩ ✏ ✓ ✕ ✥ ✢ ✖ ✛ ✏ ✔ ✣ ✛ ✔ ✖ ✫ ✕ ✎ ✏ ✒✓ ✏ ✔✕ ✔ ✖ ✛ ✔ ✖ ✕ ✥ ✥ ✢ ✜ ✕

• Client

★ ✮ ✢ ✔ ✛ ✓ ✘ ✚ ✢ ✖ ✕ ✣ ✏ ✙ ✦ ✕ ✜ ✖ ✣

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Structure

Leaf

• peration()

Client Component

• peration()

addComponent() removeComponent() getChild() Composite

• peration()

addComponent() removeComponent() getChild() 0..* 0..* +children

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Collaborations

• Collaborations

– Client uses component class interface to interact with objects in composite structure. – If recipient is:

✁ ✂ ✄ ✆ ✝ ✞ ✟ ✄ ✠ ✡ ✄ ☛ ☞ ✌ ✆✍ ✎✏ ✄ ✎ ✎ ✑ ✟ ✄ ✒ ☞ ✏ ✓ ✁ ✔ ✕ ✗✘ ✕ ☛ ✑ ☞ ✄ ✞ ✟ ✄ ✠ ✡ ✄ ☛ ☞ ✝ ✕ ✟✚ ✆ ✟ ✎ ✄ ✎ ☞ ✕ ✒ ✌ ✑ ✏ ✎ ✟ ✄ ✍

SLIDE 20

• ✁

✂ ✄ ✄☎ ✆ ✝ ✞ ☎ ✟ ✠ ✄ ✡ ✝ ✟ ☛ ☞ ✌ ✍ ✎ ✏ ✍✑ ✒ ✑ ✓ ☛ ☛ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✝ ✘ ✛ ✂ ✄ ✄☎ ✝ ✂ ✘ ✚✜ ✖ ✢ ✚ ✟ ✝ ✚ ✑ ✒ ✑

Consequences

✁ ✤ ✥ ✧ ✥ ★✩ ✪ ✫ ✬ ✭ ✮ ✯ ✰ ✱ ✲ ✳ ✴✵ ✶ ✳ ✯ ✷ ✸ ✴ ✺ ✰ ✵ ✲ ✻✼ ✲ ✯ ✴ ✵ ✲ ✻✼ ✺ ✴ ✽ ✲ ✾ ✿ ✴✵ ✱ ✯ ❀ ❂ ❃ ❄ ❅❆ ❅ ❇ ❅ ❈ ❉❊ ❋

• ❅❆

❍ ❊ ■ ❏ ❅ ❅ ❑ ▲ ❅ ❊ ❍ ▼ ❉ ▲ ❈

• ◆
• ❍
• ❇

❅

• ❍

❊ ❉ ❆ ❉ ❋ ▼ ■ ❍ ❉ ❖ ❅ ❉❊ ■ ◆ ▲ ■ ▼

• ❍

❅ ■ P ◗ ❅ ❊ ❍ ❂ ❘ ❈

• ◆
• ❍
• ❇

❅ ■ P ◗ ❅ ❊ ❍ ▼ ❊ ❉ ❆ P ❅ ❊ ■ ◆ ▲ ■ ▼ ❅ ❏

• ❆

❍ ■ ◆ ■ ❈ ❅ ❊ ■ ◆ ▲ ❋ ❅ ❑ ■ P ◗ ❅ ❊ ❍ ▼ ❙ ❯ ❄

• ❊

❄

• ❆

❍ ❱ ❈ ❆ ❊ ❉ ❆ P ❅ ❊ ■ ◆ ▲ ■ ▼ ❅ ❏ ❙ ❉ ❆ ❏ ▼ ■ ■ ❆ ✬ ❲ ✮ ❳ ✴ ✯ ✵ ✺ ✷ ✴❨ ✱ ✯ ✷ ✻ ✼ ✺ ✴ ✳ ❂ ❩ ❄ ❅ ❊ ❋

• ❅❆

❍ ■ ❆ ❋ ❬ ❆ ❅ ❅ ❏ ▼ ❍ ■ ❖ ❆ ■ ❯ ❄ ■ ❯ ❍ ■

• ❆

❍ ❅ ❈ ❉ ❊ ❍ ❯

• ❍

❄ ■ ❆ ❅

• ❆

❍ ❅ ❈ ❭ ❉ ❊ ❅

• ❆

▼ ❍ ❅ ❉ ❏ ■ ❭ ❇ ❉ ❈

• ■

❱ ▼

• ◆

▲ ❋ ❅ ◆ ❅❆ ❍ ❉ ❍

• ■

❆ ▼ ■ ❭ ▲ ❈

• ◆
• ❍
• ❇

❅ ▼ ❉ ❆ ❏ ❊ ■ ❆ ❍ ❉

• ❆

❅ ❈ ▼ ✬ ❲ ✮ ❳ ✴ ✯ ✷ ✱ ✴ ✮ ✯ ✷ ✴ ✳ ✱ ✲ ✮ ❪ ❪ ❨ ✴ ❫ ❳ ✷ ❨ ❪ ✯ ✲ ❴ ✵ ✲ ✻✼ ✲ ❨ ✴❨ ✱ ✯ ❵ ❛ ✩ ✫❜ ❝ ❞ ❜ ✧ ✪ ❜ ❢ ✥ ✫ ✬ ❲ ✮ ❳ ✴ ✯ ✷ ✱ ❣ ✮ ✳ ❪ ✴ ✳ ✱ ✲ ✱ ✲ ✳ ✴ ✯ ✱ ✳ ✷ ✵ ✱ ✱ ❣ ✴ ✵ ✲ ✻✼ ✲ ❨ ✴❨ ✱ ✯ ✲ ❴ ✮ ✵ ✲ ✻✼ ✲ ✯ ✷ ✱ ✴ ❀ ❤ ❴ ✰ ✲ ✶ ❫ ✮ ❨ ✱ ✮ ✵ ✲ ✻✼ ✲ ✯ ✷ ✱ ✴ ✱ ✲ ❣ ✮ ✸ ✴ ✲ ❨ ✺ ✰ ✵ ✴ ✳ ✱ ✮ ✷ ❨ ✵ ✲ ✻✼ ✲ ❨ ✴❨ ✱ ✯ ✰ ✲ ✶ ❣ ✮ ✸ ✴ ✱ ✲ ❪ ✲ ✳ ✶ ❨ ✐ ✱ ✷ ✻ ✴ ✵ ❣ ✴✵ ❳ ✯ ❀

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Question?

• Why is Composite considered a design pattern and

not just an example of polymorphism?

✥ ✦ ✧ ✩✪ ✫ ✬✧ ✩✭ ✮✯ ✭ ✬ ✰ ✱ ✧ ✲ ✭ ✧ ✬✳ ✴ ✱ ✵ ✫ ✬ ✱ ✫ ✬✧ ✯ ✭ ✶ ✷ ✮ ✭ ✹ ✯ ✺ ✰ ✬ ✮ ✱ ✭ ✩ ✹ ✧ ✪ ✱ ✧ ✻ ✪ ✹ ✰ ✭ ✫ ✬ ✱ ✷ ✯ ✧ ✬ ✭ ✼ ✭ ✽ ✵ ✧ ✩ ✱ ✬ ✼ ✹ ✭ ✮ ✱ ✺ ✧ ✪ ✩ ✭ ✮ ✮ ✭ ✳ ✰ ✳ ✱ ✧ ✹ ✼ ✪ ✩ ✧ ✾ ✰ ✱ ✪ ✶ ✬ ✭ ✲ ✧ ✬ ✩ ✹ ✰ ✽ ✧ ✬ ✱ ✺ ✧ ✩ ✹ ✧ ✪ ✱ ✰ ✭ ✳ ✭ ✼ ✪ ✩✭ ✳ ✱ ✪ ✰ ✳ ✧ ✹ ✩ ✶ ✪ ✬ ✬ ✱ ✺ ✪ ✱ ✽ ✭ ✱ ✺ ✺ ✭ ✶ ✲ ✬ ✪ ✩ ✭ ✶ ✶ ✧ ✩ ✱ ✰ ✭ ✳ ✭ ✼ ✱ ✺ ✧ ✬✧ ✭ ✽ ✵ ✧ ✩ ✱ ✬ ✪ ✳ ✲ ✪ ✶ ✬ ✭ ✫ ✬✧ ✬ ✱ ✺ ✧ ✬ ✪ ✮ ✧ ✰ ✳ ✱ ✧ ✹ ✼ ✪ ✩ ✧ ✪ ✬ ✱ ✺ ✧ ✭ ✽ ✵ ✧ ✩ ✱ ✬ ✰ ✱ ✺ ✭ ✶ ✲ ✬ ❁ ✥ ❂ ✺ ✪ ✱ ✰ ✬ ✾ ✱ ✺ ✧ ✩✭ ✮✯ ✭ ✳ ✧ ✳ ✱ ✰ ✳ ✱ ✧ ✹ ✼ ✪ ✩ ✧ ✰ ✬ ✳ ✭ ✱ ✰ ✮✯ ✶ ✧ ✮ ✧ ✳ ✱ ✧ ✲ ✽ ✷ ✲ ✰ ✼ ✼ ✧ ✹ ✧ ✳ ✱ ✱ ✷ ✯ ✧ ✬ ✭ ✼ ✶ ✧ ✪ ✻ ✧ ✬ ✾ ✽ ✫ ✱ ✪ ✶ ✬ ✭ ✽ ✷ ✱ ✺ ✧ ✩ ✭ ✮✯ ✭ ✬ ✰ ✱ ✧ ❃ ✺ ✰ ✩ ✺ ✺ ✭ ✶ ✲ ✬ ✶ ✧ ✪ ✻ ✧ ✬ ❁ ❂ ✺ ✧ ✹ ✧ ✼ ✭ ✹ ✧ ✾ ✱ ✺ ✧ ✩ ✶ ✰ ✧ ✳ ✱ ✩✪ ✳ ✫ ✬✧ ✱ ✺ ✧ ✯ ✹ ✰ ✮ ✰ ✱ ✰ ✻ ✧ ✶ ✧ ✪ ✼ ✪ ✳ ✲ ✱ ✺ ✧ ✩✭ ✮✯ ✭ ✬ ✰ ✱ ✧ ✩✭ ✶ ✶ ✧ ✩ ✱ ✰ ✭ ✳ ✭ ✼ ✶ ✧ ✪ ✻ ✧ ✬ ✰ ✳ ✱ ✧ ✹ ✩ ✺ ✪ ✳ ❄ ✧ ✪ ✽✶ ✷ ✾ ✪ ✳ ✲ ✧ ✪ ✬ ✰ ✶ ✷ ✽ ✫ ✰ ✶ ✲ ✩✭ ✮✯ ✶ ✧ ❅ ✬ ✱ ✹ ✫ ✩ ✱ ✫ ✹ ✧ ✬ ✹ ✧ ✩ ✫ ✹ ✬ ✰ ✻ ✧ ✶ ✷ ❁

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

The Iterator Pattern

[Gamma et al, pp 257-271]

✁ ✂ ✪ ✳ ✷ ✬ ✱ ✹ ✫ ✩ ✱ ✫ ✹ ✧ ✬ ✹ ✧ ✄ ✫ ✰ ✹ ✧ ✬ ✫ ✯ ✯ ✭ ✹ ✱ ✼ ✭ ✹ ✰ ✱ ✧ ✹ ✪ ✱ ✰ ✳ ❄ ✭ ✻ ✧ ✹ ✪ ✶ ✶ ✧ ✶ ✧ ✮ ✧ ✳ ✱ ✬ ✭ ✼ ✱ ✺ ✧ ✬ ✱ ✹ ✫ ✩ ✱ ✫ ✹ ✧ ✁ ☎ ✭ ✹ ✧ ❅ ✪ ✮✯ ✶ ✧ ✾ ✰ ✱ ✧ ✹ ✪ ✱ ✰ ✳ ❄ ✭ ✻ ✧ ✹ ✩✭ ✳ ✱ ✧ ✳ ✱ ✬ ✭ ✼ ✪ ✻ ✧ ✩ ✱ ✭ ✹✆

for (int i=0; i < v.size(); i++) { … Object o = v.elementAt(i); … }

Move to next element in list Current element First element Last element

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

The Iterator Pattern

• Iteration allows a program to successively

visit each element in a container class

– I.e. over any class that contains a collection of elements

• List (Vector), Tree, Hash Table, Graph, …

SLIDE 21

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Iterators in Java

✥ ✦ ✧ ✩ ✧ ✪ ✫ ✩ ✬ ✭ ✮ ✯ ✰ ✧ ✱ ✬ ✰ ✲ ✯ ✳ ✩✴ ✯ ✮ ✩ ✬ ✭ ✮ ✯ ✰ ✧ ✵ ✪ ✧ ✶ ✮ ✯ ✰ ✧ ✭ ✷ ✯ ✮ ✸ ✮ ✺ ✭ ✮ ✭ ✻ ✴ ✮ ✬ ✭ ✶ ✮ ✴ ✮ ✺ ✩ ✪ ✧ ✳ ✩ ✬ ✷ ✸ ✯ ✧ ✼ ✶ ✰ ✧ ✮ ✭ ✯ ✧ ✩ ✬ ✮ ✸ ✱ ✩

public interface Enumeration { // Returns true as long as there are more // elements to visit boolean hasMoreElements(); // Returns next element to visit Object nextElement(); }

✽ ✾ ✭ ✶ ✺ ✩ ✷ ✩ ✫ ✩ ✧ ✮ ✿ ✯ ✷ ✷ ✻ ✩ ✬ ✩ ✮ ✪ ✬ ✧ ✩ ✳ ✻ ✸ ❀❁ ❂ ❃ ❄ ❅ ❁ ❆ ❁ ❀ ❃ ✩ ❇ ✭ ✶ ✮ ✷ ✸ ✰ ✧ ✶ ✩ ✽ ❈ ✬ ✳ ✩ ✬ ✰ ✵ ✲ ✯ ✴ ✯ ✮ ✭ ✮ ✯ ✰ ✧ ✧ ✰ ✮ ✴ ✱ ✩ ✶ ✯ ✵ ✯ ✩ ✳ ✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✁ ✒ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✒ ✁ ✒

Iterators in Java

✽ ✤ ✥ ✦ ✧ ✩ ✪ ✫ ✭✮

// Returns all elements in the Vector public Enumeration elements();

✯ ✰ ✱ ✲ ✳ ✴ ✵ ✪ ✳ ✶✷ ✧ ✮

// Returns all elements in the Hashtable. // That is, returns all values that have been // entered into the hashtable via put public Enumeration elements();

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁ ✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁ ✒ ✁

Example: Using an Iterator with a Vector

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎ ✁ ✒ ✁ ✓ ☞ ☞ ✔ ✕ ✖ ✖ ✗ ✗ ✘ ✚ ✞ ✘ ✛ ✄ ☎ ☎✆ ✞ ✄ ✘ ✚✜ ✖ ✢ ✚ ✠ ✞ ✚ ✁ ✒ ✁

Using an Iterator with a Vector

• Client creates an iterator

by calling the Vector’s elements method

✁ ✂ ✄ ✆ ✝ ✞ ✠ ✡☛ ☞ ✌ ✍ ✎ ✏ ✑ ✡✓ ✎ ☞ ✑ ✔ ✡ ☞ ✕ ✔ ✖ ✡☛ ☞ ✕ ✔✗

• Client then accesses

elements of Vector via Enumeration’s methods

for (Enumeration e = v.elements(); e.hasMoreElements();) { Object o = e.nextElement(); … }

SLIDE 22

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Implementation of Iterator for Vector

• Vector must implement method

– Enumeration elements () – Must return an implementation of the Enumeration interface – Iterator must successively return values in vector

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Classes for Vector Iterator

class Vector { … public Enumeration elements () { return new VectorEnumeration (this); } … }

How we might implement an enumeration in a vector. (Not necessarily how it is really implemented.)

import java.util.Vector; class VectorEnumeration { // Represents where we are in the vector private int currentElement = 0; // The vector we are iterating through private Vector v; public boolean hasMoreElements () { return (currentElement < v.size()); } public Object nextElement () { Object returnElement = v.get (currentElement); currentElement++; return returnElement; } public VectorEnumeration (Vector v) { this.v = v; } }

SLIDE 23

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

General Form of Iterator

Abstract representation

• f container

Concrete representation

• f container - e.g. Vector

Concrete iterator for specific container class - e.g. iterator for Vector is different from iterator for hashtable Enumeration interface

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Relation to Quality Attributes

• Modifiability

– Separates iteration behaviour from specifics of container class – Therefore can change container class without impacting code that iterates over it

• Performance

– May be some minor performance penalty through indirection in iterator

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Builder Design Pattern

[Gamma et. al. pp. 97-106]

• Intent

– Separate the construction of a complex object from its representation

• ✓

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Applicability

• Use the Builder pattern when…

– The algorithm for creating a complex object should be independent of the parts that make up the object and how they’re assembled – The construction process must allow different representations for the object that’s constructed

SLIDE 24

• ✒

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Participants

• ✁

✂ ☎ ✆✝ ✞ ✟ ✠ ✡ ☛ ✌✍ ✎ ✏ ✎ ✌✑ ✒✓ ✒ ✔ ✑ ✕ ✖ ✒ ✍ ✕ ✎ ✓ ✕ ✌ ✖ ✏ ✒ ✍ ✌ ✏ ✙ ✖ ✍ ✖ ✌ ✒ ✕ ✎ ✓ ✚ ☛ ✒ ✖ ✕ ✑ ✙ ✏ ✒ ☛ ✖ ✙ ✛ ✜ ✍ ✕ ✙ ✔ ✣ ✌✍ ✕

• ✤

✥ ✦✧ ✟ ✞ ★ ✞ ✁ ✂ ☎ ✆✝ ✞ ✟ ✠ ✩ ✙ ✓ ✑ ✕ ✖ ✜ ✍ ✕ ✑ ✒✓ ✛ ✒ ✑ ✑ ✌ ✪ ✔✫ ✌ ✑ ☛ ✒ ✖ ✕ ✑ ✙ ✏ ✕ ✬ ✌ ☛ ✖ ✙ ✛ ✜ ✍ ✕ ✔ ✭ ✎ ✪ ☛ ✫ ✌ ✪ ✌ ✓ ✕ ✎ ✓ ✚ ✕ ✬ ✌ ✮ ✜ ✎ ✫ ✛ ✌ ✖ ✎ ✓ ✕ ✌ ✖ ✏ ✒ ✍ ✌ ✠ ✯ ✌ ✏ ✎ ✓ ✌ ✑ ✒✓ ✛ ✰ ✌ ✌☛ ✑ ✕ ✖ ✒ ✍ ✰ ✙ ✏ ✕ ✬ ✌ ✖ ✌ ☛ ✖ ✌✑ ✌ ✓ ✕ ✒ ✕ ✎ ✙ ✓ ✎ ✕ ✍ ✖ ✌ ✒ ✕ ✌✑ ✠ ✱ ✖ ✙ ✲ ✎ ✛ ✌ ✑ ✒✓ ✎ ✓ ✕ ✌ ✖ ✏ ✒ ✍ ✌ ✏ ✙ ✖ ✖ ✌ ✕ ✖ ✎ ✌ ✲ ✎ ✓ ✚ ✕ ✬ ✌ ☛ ✖ ✙ ✛ ✜ ✍ ✕

• ✳

☎ ✟ ✞ ✧ ★ ✥ ✟ ✠ ✩ ✙ ✓ ✑ ✕ ✖ ✜ ✍ ✕ ✑ ✒✓ ✙ ✔ ✣ ✌✍ ✕ ✜ ✑ ✎ ✓ ✚ ✕ ✬ ✌ ✮ ✜ ✎ ✫ ✛ ✌ ✖ ✎ ✓ ✕ ✌ ✖ ✏ ✒ ✍ ✌

• ✴

✟ ✥ ✝ ✂ ✧ ★ ✠ ✵ ✌☛ ✖ ✌✑ ✌ ✓ ✕ ✑ ✕ ✬ ✌ ✍ ✙ ✪ ☛ ✫ ✌ ✶ ✙ ✔ ✣ ✌✍ ✕ ✜ ✓ ✛ ✌ ✖ ✍ ✙ ✓ ✑ ✕ ✖ ✜ ✍ ✕ ✎ ✙✓ ✷ ✠ ✹ ✓ ✍ ✫ ✜ ✛ ✌ ✑ ✍ ✫ ✒ ✑ ✑ ✌✑ ✕ ✬ ✒ ✕ ✛ ✌ ✏ ✎ ✓ ✌ ✕ ✬ ✌ ✍ ✙ ✓ ✑ ✕ ✎ ✕ ✜ ✌ ✓ ✕ ☛ ✒ ✖ ✕ ✑ ✺ ✎ ✓ ✍ ✫ ✜ ✛ ✎ ✓ ✚ ✎ ✓ ✕ ✌ ✖ ✏ ✒ ✍ ✌ ✑ ✏ ✙ ✖ ✒ ✑ ✑ ✌ ✪ ✔ ✫ ✎ ✓ ✚ ✕ ✬ ✌ ☛ ✒ ✖ ✕ ✑ ✎ ✓ ✕ ✙ ✕ ✬ ✌ ✏ ✎ ✓ ✒ ✫ ✖ ✌ ✑ ✜ ✫ ✕

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Example: JDOM SAXBuilder

• Constructs products from an XML document.

✥ ✦ ✧ ★ ✪ ✫ ✬ ★ ✭ ✮ ✯ ✬ ✱ ✲ ✳✴ ✵ ★ ✶ ✪ ★ ✬ ✷ ✫ ✸ ✶ ✮ ★ ✺ ✮ ✻ ✶ ✬ ✸ ★ ✬ ✼ ✫ ✮ ✻ ✶ ✬ ✸ ★ ✸ ✮ ✧ ★ ✲ ✳ ✴ ✪ ✯ ✭ ✽ ✾★ ✿ ✮ ✶ ✿ ✪ ✿ ✯ ✮ ✫ ❀ ✫ ★ ✸ ✫ ✮ ✸ ❁ ✽ ✫ ❂✪ ★ ✬ ✱ ❃ ✯ ✿ ✮ ★ ✿ ✮ ❄ ✶ ✿ ✪❂ ★ ✬ ✷ ✶ ❁ ✯ ✽ ✮ ✮ ✧ ★ ✮ ✶❅ ✸ ✶ ✿ ✪ ✪ ✶ ✮ ✶ ✮ ✧ ✶ ✮ ✫ ✮ ★ ✿ ✭✯ ✽ ✿ ✮ ★ ✬ ✸ ❆ ❇ ✦ ✧ ★ ✪ ★ ❀ ✶ ✽ ❂ ✮ ✭✯ ✿ ✭ ✬ ★ ✮ ★ ❁ ✽ ✫ ❂✪ ★ ✬ ✫ ✸ ❈ ❉ ✲ ❄ ✶ ✿ ✪❂ ★ ✬ ❊ ❋ ✧ ✫ ✭ ✧ ✭ ✬ ★ ✶ ✮ ★ ✸ ✶ ✮ ✬ ★ ★ ✯ ❀ ★ ❂ ★ ✾★ ✿ ✮ ✸ ✶ ✿ ✪ ✪ ✶ ✮ ✶ ❆ ❇ ❄ ✯ ❋ ★

• ★

✬ ❊ ✶ ✽ ✸ ★ ✬ ✭✯ ✽ ❂ ✪ ✸ ✽ ✻ ✻ ❂ ■ ✶ ✪ ✫ ❀ ❀ ★ ✬ ★ ✿ ✮ ✭✯ ✿ ✭ ✬ ★ ✮ ★ ❁ ✽ ✫ ❂✪ ★ ✬ ✮ ✯ ✭ ✬ ★ ✶ ✮ ★ ✶ ✮ ✯ ✮ ✶ ❂ ■ ✪ ✫ ❀ ❀ ★ ✬ ★ ✿ ✮ ✬ ★ ✻ ✬ ★ ✸ ★ ✿ ✮ ✶ ✮ ✫ ✯ ✿ ❊ ✸ ✽ ✭ ✧ ✶ ✸ ✶ ❅ ✬ ✶ ✻ ✧ ✫ ✭ ✶ ❂ ✪ ✫ ✶❅ ✬ ✶ ✾ ✯ ❀ ✮ ✧ ★ ✪ ✯ ✭ ✽ ✾★ ✿ ✮ ✯ ✬ ✶ ✸ ✮ ✬ ✫ ✿❅ ✯ ❀ ✶ ❂ ❂ ✫ ✮ ✸ ✮ ✶❅ ✸ ❆ ❑ ▲ ▼ ◆ ❖ ◆ ❖ ◗ ▼ ❘ ❙ ◆ ❖ ❚❯ ❘ ❱ ❙ ❲ ❳ ❙ ▼ ❯ ❖ ❯ ❩ ❘ ❬ ❘ ❙ ◆ ❭ ❱ ❭ ❪ ❫ ❭ ❱ ❖ ❙ ❬ ❴ ❫ ❙ ◆ ❭ ❱ ❘ ❱ ❵ ❬ ❯ ❩ ❬ ❯ ❖ ❯ ❱ ❙ ❘ ❙ ◆ ❭❱ ❛ ▲ ▼ ❯ ❵ ◆ ❬ ❯ ❫ ❙ ❭ ❬ ❵ ❯ ❪ ◆ ❱❯ ❖ ❙ ▼ ❯ ❭ ❬ ❝❘ ❱ ◆ ❞ ❘ ❙ ◆ ❭ ❱ ❭ ❪ ❙ ▼ ❯ ❩ ❬ ❭ ❵ ❴ ❫ ❙ ❡ ❲ ❴ ❙ ❵ ❭ ❯ ❖ ❱ ❭ ❙ ❫ ❘ ❬ ❯ ◗ ▼ ❯ ❙ ▼ ❯ ❬ ◆ ❙ ◆ ❖ ❭ ❬ ❝ ❘ ❱ ◆ ❞ ◆ ❱ ❝ ❣ ❪ ❭ ❬ ❯ ❤ ❘ ❚ ❩ ✐ ❯ ❥ ❘ ❙ ❬ ❯ ❯ ❡ ❘ ❱ ◆ ❚ ❘ ❝ ❯ ❡ ❭ ❬ ❘ ❖ ❙ ❬ ◆ ❱❝ ❛

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Structure

ConcreteBuilder buildPart() getProduct() Product Director Builder buildPart() <<creates>>

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Collaborations

• The client creates the Director object and

configures it with the desired Builder object

• Director notifies the Builder whenever a part
• f the product should be built
• Builder handles requests from the director

and adds parts to the product

• The client retrieves the product from the

builder

SLIDE 25

• ✁

✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Collaborations (cont’d)

aClient : Client aDirector : Director aConcreteBuilder : ConcreteBuilder new ConcreteBuilder() new Director(aConcreteBuilder) construct() buildPartA() buildPartB() buildPartC() getResult()

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Consequences

• Benefits

– It lets you vary a product’s internal representation – It isolates code for construction and representation – It gives you finer control over the construction process (object constructed step-by-step under the director’s control)

• Disadvantages

– N/A

• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Relationship between Composite, Iterator, and Builder

• Builder, Composite and Iterator Design Patterns often

work together

• ✁

✂ ✄ ✆ ✂ ✝ ✞✟ ✆ ✂ ✠ ✆ ✡ ☛ ✝ ✌✍ ✄ ✎ ✏ ☛ ✝ ✌✍ ✒ ✝ ✒ ✓ ✔ ✆ ✄ ✞ ✠ ✕ ✓ ✖✗ ✓ ✒ ✝ ✆ ✄ ✘ ✕ ✓ ✖✗ ✓ ✒ ✝ ✆ ✄ ✒ ✝ ✞ ✆ ☛ ✎ ✞ ☛ ✒ ✄ ✆ ✂ ✄ ✙ ✆ ✄ ✎ ✠ ✆ ✓ ✎ ✆ ✓ ✆ ✎ ✠ ✚ ✄ ✎ ✒ ✄ ✆ ✂ ✄ ✝ ✎ ✛ ✂ ✝ ✌✍ ✎ ✄ ✞

• ✁

✁ ✂ ✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Summary of Patterns Discussed…

• Creational Patterns:

✘ ✥ ✏ ✒ ✆ ✎ ✠ ✛ ✆ ✦ ✠ ✛ ✆ ✓ ✎✧ ✘ ✡ ☛ ✝ ✌✍ ✄ ✎

• Structural Patterns:

✘ ✥ ✍ ✠ ✗ ✆ ✄ ✎ ✘ ✕ ✓ ✖✗ ✓ ✒ ✝ ✆ ✄ ✘ ✦ ✠ ★ ✠ ✍ ✄ ✘ ✦ ✌ ✧ ✩ ✄ ✝ ✟ ✂ ✆

• Behavioural Patterns:

✘ ✙ ✆ ✄ ✎ ✠ ✆ ✓ ✎ ✘ ✪ ✏ ✒ ✄ ✎ ✚ ✄ ✎

SLIDE 26

• ✁
• ✂

✄ ☎ ☎✆ ✝ ✞ ✟ ✆ ✠ ✡ ☎ ☛ ✞ ✠ ☞ ✌ ✍ ✎ ✏ ✑ ✎✒ ✓ ✒ ✔ ☞ ☞ ✕ ✖ ✗ ✗ ✘ ✘ ✙ ✛ ✞ ✙ ✜ ✄ ☎ ☎✆ ✞ ✄ ✙ ✛✢ ✗ ✣ ✛ ✠ ✞ ✛ ✒ ✓ ✒

Final Points

• Design Patterns encapsulate generic solutions to

commonly occurring problems in design

✘

• ✎

✝ ✆ ✆ ✄ ✞ ✔ ✎ ✓ ✖ ✄ ✁ ✗ ✄ ✎ ✝ ✄ ✞ ✛ ✄ ✝ ✞ ✖ ☛ ✌ ✆ ✝ ✗ ✌ ✄ ✛ ✓ ✞ ✆ ✄ ✁ ✆ ✒

• The Gang of Four text was the first widely read work
• n patterns, and remains a widely cited and used

reference

• Patterns rarely exist on their own, they often work

together to solve complex problems

• There are always costs and benefits to applying a

given pattern, which must be carefully weighed.