1. CSC 313 – Advanced Programming Topics

2. Design Pattern Intent  Each design pattern is a tool  Like all tools, have reason for being

3.  Each design pattern is a tool  Like all most tools, have reason for being  Explains when & where to use pattern  Tool used improperly is sad  Ryan Seacrest is truly depressed  Programmer’s goal is to match need to pattern  Coding is simple when used properly  More importantly, life just sucks when you don’t Design Pattern Intent

4. Strategy Pattern Intent  Makes family of algorithms interchangable  Avoid duplicating code across classes & projects  Allows to change algorithm dynamically  Fairly straightforward to implement  Set of behaviors (strategies) implementing interface  Context has field of the interface type  Performs action by calling method on field

5. Observer Pattern Intent  What is the intent of observer pattern?

6. Observer Pattern Intent  Efficiently perform 1-to-many communication  Easy notification of Observers when event occurs  Can also use to break mutual dependency  UML class diagram cycles split and managed  Dirty, ugly, incredibly useful hack

7. Registering an Observer  Efficiently perform 1-to-many communication  Subject adds & removes Observers as needed  Adding is simple  Events also simple, call Observers’ update method  Removing not so simple, but not very hard either  Requires some means of holding Observers  Array *  ArrayList or LinkedList  HashMap

8. Registering an Observer

9. Getting the Word Out  Calling Observers’ update methods is simple  Good ways of passing data is difficult  Bad to rely on simple parameters for method  Updating parameters requires changing all code  Can use strategy pattern to supply information  Yay! Keeps our classes independent of each other

10. Good, bad, & ugly  Efficiently perform 1-to-many communication  Strategy pattern defines functionality  But observer pattern only for communication  Observers & subject independent of each other  Subject & strategy semi-independent of other  Observer & strategies entirely inter-dependent  Observer must know Strategy’s algorithm

11. Push vs. Pull  So far discussed pattern’s push model  Subject pushes data onto the Observers  At all times, must keep Observer prepared  Much harder to change code & what happens  Could instead use pattern’s pull model  Subject provides an instance to the Observers  To get data, Observers call instance’s methods  Extend instance’s class to provide additional data  But, Observers using original methods still work

12. Problems with Pull Model  Pull model also has its problems  Adds many method calls to get access to data  Can cause problems in multi-threaded systems  Interfere with other design patterns, if also used  These problems are both easier & harder  Only with later concept from CSC330 & CSC313  But these issues cannot be easily avoided…  …and very serious on large real-world systems

13. Other Observer Gotchas  Observer only needs some of the events  Still performs 1-to-many communication  Subject cannot filter events for each Observer  But easier to add another Observer to filter  Subject has multiple sets of events to observe  Could choose to rely on single Observer interface  Java AWT/Swing libraries use this approach  Multiple Observer interfaces each with 1 event  Simpler, but less efficient if multiple events wanted

14. For Next Lecture  Read pages 70 – 74 in book  What is the Observable object in Java?  How would one use it?  Why would anyone write it that way?