 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 specification  Have 4 components  States  Transitions  Conditions  Actions  Must have one initial state  May have multiple final states

Idle Playing Messages Rewinding Recording Message Waiting for 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 light goes on Action Condition Incoming call detected Condition End of Call or tape runs out Press Cancel button Ready to receive button goes out Condition Action

State 2 Can be partitioned to State 2.1State 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?