More Related Content
Viewers also liked
Viewers also liked (8)
Similar to Design Patterns Summer Course 2010-2011 - Session#1
Similar to Design Patterns Summer Course 2010-2011 - Session#1 (20)
Recently uploaded
Recently uploaded (20)
Design Patterns Summer Course 2010-2011 - Session#1
- 1. Know me well to get your goals! Session # 5 MuhamadHesham
- 2. Agenda Why design patterns? Dynamic behaviors everywhere Our pattern exposed Applicability Design Changes Why all of this?
- 3. Where are we? Great Software 1. Make sure your software does what customer wants it to do
- 4. Where are we? Great Software 1. Make sure your software does what customer wants it to do 2.Apply basic OO princibles to add more flexibility
- 5. Where are we? Great Software 1. Make sure your software does what customer wants it to do 2.Apply basic OO princibles to add more flexibility 3.Strive for maintainability and reusable design
- 6. Guess what? “The one constant in software development”
- 7. Guess what? “The one constant in software development” CHANGE
- 8. Why Design Patterns? Job Requirements
- 9. Pocket Money You: Dad, I need pocket money.
- 10. Pocket Money Angry Dad
- 11. Pocket Money Troubled Dad
- 12. Pocket Money Happy Dad
- 13. Pepsi Machine
- 14. Pepsi State Machine Out of Pepsi No Money insert money pepsi > 0 eject money pepsi = 0 Pepsi Sold Has Money order pepsi
- 15. Platformer Game
- 16. Enemy State Machine reach cliff after a while Running Idle
- 17. Coding by Sense® /// <summary> /// Paces back and forth along a platform, waiting at either end. /// </summary> public void Update(GameTimegameTime) { if (State == EnemyState.Idle) { // If time-out go-to state Running // Else wait for some amount of time } else if (State == EnemyState.Running) { // Update enemy position // If reach cliff go-to state Idle } }
- 18. Messenger
- 19. Messenger State Machine Available Offline sign in available busy away available Away Busy away busy All states are connected to offline via sign out
- 20. Coding by Sense® /// <summary> /// Occurs when a remote client sends a message /// </summary> public void OnMessageSent(Message msg) { if (State == MessengerState.Aways) { } else if (State == MessengerState.Busy) { } ... … }
- 21. Coding by Sense® /// <summary> /// Occurs when a remote client sends a message /// </summary> public void OnContactSignIn(Message msg) { if (State == MessengerState.Aways) { } else if (State == MessengerState.Busy) { } ... … }
- 22. Coding by Sense® /// <summary> /// Occurs when a remote client sends a message /// </summary> public void OnNudge(Message msg) { if (State == MessengerState.Aways) { } else if (State == MessengerState.Busy) { } ... … }
- 23. Our Code Smells Bad Violates Open Closed Principle. Further additions may cause bugs. State transitions are buried between if-else.
- 24. Exploring the pattern Let’s Google it!
- 25. Explaining the pattern Pattern class diagram
- 26. Explaining the pattern Participants Context defines the interface of interest to clients. maintains an instance of a ConcreteState subclass that defines the current state. State defines an interface for encapsulating the behavior associated with a particular state of the Context. ConcreteState subclasses each subclass implements a behavior associated with a state of the Context.
- 27. Explaining the pattern Example
- 28. How they interact? Set Initial State Context Context Foo Foo( ) Current-State Context
- 29. Applicability What are the symptoms should I take care of ?
- 30. Applicability But take care! OVER DESIGN nightmare
- 31. Design Challenges Who defines the state transitions? (Classes Dependency)
- 32. Design Challenges Creatingand destroyingState objects (Memory Management)
- 33. Further Reading What’s Next State Pattern: Chapter 10 in Head First Strategy Pattern: Chapter 1 in Head First GoF: Behavioral Pattern Section Section: Enhance way of drawing shapes
- 34. Finally Where are our scientists? HF & DS authors. Taha & Elmasri. Previous: Algorithm, Algebra, 1,2,3, Camera, NASA. Hospital. Nueclar scientist. Stat. What about efforts? Thomas Edison. Reading books. EbnMakhld. Quotes. Why all of this? “No pain, no gain” Anonymous. “لا يُستطاع العلم براحة الجسم” يحى بن كثير “My inventions comes from 2% inspiration and 98% of efforts” Thomas Edison. “Science is what we understand well enough to explain to a computer. Art is everything else we do” Donald Knuth.
- 35. Thank you ... Questions? mhesham.fcis@gmail.com
Editor's Notes
- CollaborationsContext delegates state-specific requests to the current ConcreteState object. A context may pass itself as an argument to the State object handling the request. This lets the State object access the context if necessary. Context is the primary interface for clients. Clients can configure a context with State objects. Once a context is configured, its clients don't have to deal with the State objects directly. Either Context or the ConcreteState subclasses can decide which state succeeds another and under what circumstances.
- CollaborationsContext delegates state-specific requests to the current ConcreteState object. A context may pass itself as an argument to the State object handling the request. This lets the State object access the context if necessary. Context is the primary interface for clients. Clients can configure a context with State objects. Once a context is configured, its clients don't have to deal with the State objects directly. Either Context or the ConcreteState subclasses can decide which state succeeds another and under what circumstances.
- Use the State pattern in either of the following cases:An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
- Use the State pattern in either of the following cases:An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
- Who defines the state transitions? The State pattern does not specify which participant defines the criteria for state transitions. If the criteria are fixed, then they can be implemented entirely in the Context. It is generally more flexible and appropriate, however, to let the State subclasses themselves specify their successor state and when to make the transition. This requires adding an interface to the Context that lets State objects set the Context's current state explicitly. Decentralizing the transition logic in this way makes it easy to modify or extend the logic by defining new State subclasses. A disadvantage of decentralization is that one State subclass will have knowledge of at least one other, which introduces implementation dependencies between subclasses.
- Creating and destroying State objects. A common implementation trade-off worth considering is whether (1) to create State objects only when they are needed and destroy them thereafter versus (2) creating them ahead of time and never destroying them. The first choice is preferable when the states that will be entered aren't known at run-time, and contexts change state infrequently. This approach avoids creating objects that won't be used, which is important if the State objects store a lot of information. The second approach is better when state changes occur rapidly, in which case you want to avoid destroying states, because they may be needed again shortly. Instantiation costs are paid once up-front, and there are no destruction costs at all. This approach might be inconvenient, though, because the Context must keep references to all states that might be entered.