Lecture 8: Implementing Observer Pattern

1. CSC 313 – Advanced Programming Topics Lecture 8:Implementing Observer Pattern

2. Today’s Goal • Review design patterns (tools) purpose • What is needed so that a tool becomes useful? • Why can tools suck and how do we avoid this? • What does this mean for design patterns? • Observer pattern implementation discussed • How do we handle Observer addition & removal? • What do update methods need to be useful? • Why do we have to talk about pushing & pulling? • Coding “gotchas” discussed & diagnosed

3. Design Pattern Intent • Design patterns are tools • Like all tools, have reason for being

4. Design Pattern Intent • Design patterns are tools • Like all tools, have reason for being

5. Design Pattern Intent • Design patterns are tools • Like allmost tools, have reason for being

6. Design Pattern Intent • Design patterns are tools • Like allmost tools, have reason for being • Explains when & where to use pattern • When used improperly, tool is sad • Bieberalways depressed; Seacrest not much better • To be useful, need & pattern MUSTmatch • Coding is simple when used properly • More importantly, life just sucks when you don’t

7. Strategy Pattern Intent

8. Strategy Pattern Details • Make family of algorithms interchangable • Avoid duplicating code across classes & projects • Allows to change algorithm dynamically • Implementation easy when used correctly • Everything relies on interface defining behaviors • Each strategy defines method to perform some action • Write into the context class has field of interface type • Call field’s method (delegate) to perform action

9. Observer Pattern Intent

10. Observer Pattern Intent • Efficiently perform 1-to-many communication • Easy to respond dynamically when event(s) occurs • Can create many, many possible actions to occur • Update which actions used throughout execution • Can also use to break mutual dependency • UML class diagram cycles split and managed • Dirty & ugly hack that also is incredibly useful

11. Observer Pattern Examples • Where have you seen Observer Pattern?

12. Registering an Observer • Subjectadds & 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

13. Registering an Observer • Subjectadds & 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 * Anyone who did not object to this, fails.

14. Getting the Word Out • Calling Observers’ update methods is simple • But for call Observerneeds associated information • Not always clear what is best way to share this data • Must understand strengths & weaknesses of each

15. Observer’s Push Model • Easiest approach is pattern’s push model • Subject pushes data onto Observers • Parameters used in call provides all data needed • Writing & using is simple with this model, but… • Once this is defined, stuck with data to be shared • Adding data hard, since must rewrite all Observers • Removal easier, but users guessing why param exists

16. Observer’s Pull Model • Another approach using pattern’s pull model • Subjectprovides instance to Observers in the call • To get data, Observer calls instance’s methods • Extend instance’s interface to make more available • But Observers using original methods still work • Making instances simple part of this process • Will need to have family of algorithms • Used interchangeably, but only 1 used at a time

17. Observer’s Pull Model • Another approach using pattern’s pull model • Subjectprovides instance to Observers in the call • To get data, Observer calls instance’s methods • Extend instance’s interface to make more available • But Observers using original methods still work • Making instances simple part of this process • Just need to use Strategy Pattern

18. Pull Model’s Pros and Cons • Communicating using Strategy pattern means: • Observers & Subjectindependent of each other • Subject provides the strategy to Observer • Subject& strategy semi-independent of other • Subject source of event that strategy communicates • Observer needs strategy & must change together

19. Problems with Pull Model • Pull model also has its problems • May need multiple calls to get all the data • Need to consider multi-threaded access issues • Interfere with other design patterns, also possible • At the same time, problems easier & harder • If not multi-threaded, that issue can be ignored • As we will see, method calls can cost nothing • Just be careful & be certain of your decision

20. Other Observer Gotchas • Observer only needs some of the events • Intent is to perform 1-to-many communication • Subjectcannot filter events for each Observer • Better to create addition Observer to do filtering • 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

21. For Next Lecture • Read pages 70 – 74 in book • Is this part of Java; what does Observable do? • How would one use it? • Was there anyone with IQ over 80 to correct it?