How are you going to collaborate?How are you going to divide up

work?How are you going to make sure that

changes work with other people’s code?

What’s needed to write Pong?

Useful abstractions for commonly used design structure

Patterns and their consequences of use have been thought through by experienced designers

Helpful for good OO design

Describe what to do and what not to do when implementing the patterns in your project

Encapulate the things that vary from object to object as separate classes But keep common code together

Example in HFDP book: Ducks

In AI, we talk about “agents” In graphics, we talk about

(rendering) “entities”

Example: Reflex agent Reflex agent with state Goal-directed agent

Entities vs. strategies vs. state

Composite: Compose objects into tree structures to represent part-whole hierarchies, let clients treat individual objects and compositions of objects uniformly.

Strategy: Defines a family of algorithms, encapsulates each one and makes them inter-changeable. Strategy lets the algorithm vary independently from clients that use it.

State: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

Singleton: ensure a class has only one instance, and provide a global access point to it

Abstract Factory: create concrete instances of abstract interfaces

Visitor: perform an operation on an object (i.e. all elements of the scene graph) without altering the object

FrameListener: hook in to receive notices of events from an announcing object

Singleton: enforce one instance Façade: create a convenient access point

for many operations on diverse classes

One pointer to a state instance with subclasses

The state object knows under what conditions it should change to a different active state

described in Ch2 of PGAIBE, good walkthrough in HeadFirst design patterns

Eliminates the need for giant if statements Easier to extend with new substate classes

Represent a process specificationHave 4 components

States Transitions Conditions Actions

Must have one initial stateMay have multiple final states

Idle

PlayingMessages

RewindingRecordingMessage

Waitingfor call

Answering Call

A condition is an event in the external environment which triggers a transition to a new state

An action is a response sent back to the external environment or a calculation whose result is stored by the system that occurs when the transition takes place

Idle

Waiting for Call

Answering Call

Press Answer button

Ready to receive lightgoes on

Action

Condition

Incoming call detectedCondition

End of Call or tape runs out

Press Cancel button

Ready to receive button goes out

Condition

Condition

Action

State 2

Can be partitioned to

State 2.1 State 2.2

State 2.4

State 2.3

Have all states been defined?

Can you reach all the states?

Can you exit from all the states?

In each state does the system respond to all possible conditions?

How do FSMs (state transition diagrams) relate back to the idea of agents?

How would you implement state using design patterns?