Understanding the Observer Pattern: Implementation, Use Cases, and Best Practices
In this lecture, we explore the Observer design pattern, focusing on how to implement it effectively for efficient one-to-many communication. We review design patterns as essential tools, discuss strategies for adding and removing observers, and examine the intricacies of update methods. Key topics include push and pull models, the necessity of sharing data between subjects and observers, and common pitfalls in implementation. Whether you are a beginner or seasoned developer, understanding these aspects will enhance your programming skill set significantly.
Understanding the Observer Pattern: Implementation, Use Cases, and Best Practices
E N D
Presentation Transcript
CSC 313 – Advanced Programming Topics Lecture 8:Implementing Observer Pattern
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
Design Pattern Intent • Design patterns are tools • Like all tools, have reason for being
Design Pattern Intent • Design patterns are tools • Like all tools, have reason for being
Design Pattern Intent • Design patterns are tools • Like allmost tools, have reason for being
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
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
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
Observer Pattern Examples • Where have you seen Observer Pattern?
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
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.
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
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
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
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
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
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
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
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?
