Never confuse education with intelligence, you can have a PhD and still be an idiot.
- Richard Feynman -



Difference between revisions of "Design patterns - Observer"

From Juneday education
Jump to: navigation, search
(Template page - TODOs added)
 
(Description: started on writing it)
Line 2: Line 2:
 
In this chapter, we'll discuss the Observer pattern.
 
In this chapter, we'll discuss the Observer pattern.
 
===Aim of the pattern===
 
===Aim of the pattern===
The intent of this pattern is to TODO...
+
The intent of this pattern is to allow for a one-to-many relationship between one object with important state, and many interested objects, subscribing to changes in the important object. It is often described in terms of a "Subject" object which is observable by many "Observers" (or sometimes "Listeners").
 
===Problem description===
 
===Problem description===
TODO: We often have a situation where something central in our application changes its state, and many components would be interested to hear about this.
+
We often have a situation where something central (the Subject) in our application changes its state, and many components (observers) would be interested to hear about this. The Subject should be loosely coupled with any amount of observers and treat them uniformly. But the actual observers can be totally unrelated objects of very different classes.
 
<source lang="Java">
 
<source lang="Java">
/* TODO: some example code */
+
class SuperImportantClass{
</source>
+
  List interestedObjects; // what type should we use here?
 +
  // how do we populate the list with interested objects?
  
<source lang="Java">
+
  // Times they are a changing...(but Robert stays the same)
/* TODO: some example code */
+
  void stateChangesForSomeReason(){
 +
    for(Object o : interestedObjects){
 +
      //tell them about the changes, but how?
 +
    }
 +
  }
 +
}
 
</source>
 
</source>
 
+
As usual, we don't want our classes to know too much about each other, so that things stay on a high abstraction level and things can vary and change without too much impact between classes.
 
===Solution - applying the Observer Pattern===
 
===Solution - applying the Observer Pattern===
The solution to this problem is to TODO: write about how to apply the observer pattern
+
The solution to this problem is to follow the Observer pattern. As usual, there are a few variations of this pattern but we'll explain a common design for it. In order to keep the classes (Subject and Observers) loosely couples (knowing little about each others implementation details), we define two interfaces. We're gonna call the interface for the Subject <code>Observable</code> and the interface for the observers <code>Observer</code>. The <code>Observable</code> defines methods every Subject object must have:
 +
* <code>public void add(Observer o);// an observer wants to register</code>
 +
* <code>public void delete(Observer o);// unregister observer</code>
 +
* <code>public void notifyObservers(); // notify all observers</code>
  
 
<source lang="Java">
 
<source lang="Java">

Revision as of 13:36, 30 November 2016

Description

In this chapter, we'll discuss the Observer pattern.

Aim of the pattern

The intent of this pattern is to allow for a one-to-many relationship between one object with important state, and many interested objects, subscribing to changes in the important object. It is often described in terms of a "Subject" object which is observable by many "Observers" (or sometimes "Listeners").

Problem description

We often have a situation where something central (the Subject) in our application changes its state, and many components (observers) would be interested to hear about this. The Subject should be loosely coupled with any amount of observers and treat them uniformly. But the actual observers can be totally unrelated objects of very different classes.

class SuperImportantClass{
  List interestedObjects; // what type should we use here?
  // how do we populate the list with interested objects?

  // Times they are a changing...(but Robert stays the same)
  void stateChangesForSomeReason(){
    for(Object o : interestedObjects){
      //tell them about the changes, but how?
    }
  }
}

As usual, we don't want our classes to know too much about each other, so that things stay on a high abstraction level and things can vary and change without too much impact between classes.

Solution - applying the Observer Pattern

The solution to this problem is to follow the Observer pattern. As usual, there are a few variations of this pattern but we'll explain a common design for it. In order to keep the classes (Subject and Observers) loosely couples (knowing little about each others implementation details), we define two interfaces. We're gonna call the interface for the Subject Observable and the interface for the observers Observer. The Observable defines methods every Subject object must have:

  • public void add(Observer o);// an observer wants to register
  • public void delete(Observer o);// unregister observer
  • public void notifyObservers(); // notify all observers
/* TODO: some example code */
/* TODO: some example code */
/* TODO: some example code */

Another example

TODO:

/* TODO: some example code */
/* TODO: some example code */

Exercises

Task 1 - TODO: write an exercise, man!

/* TODO: some source code here */

Challenge - 1

TODO: Challenge 1

Challenge - 2

TODO: Challenge 2

Hints

TODO: If necessary, create hints for the exercise.

Suggested solutions

Expand using link to the right to see the full content.

You can download source code including suggested solutions TODO: here (github). But here are the source code for the suggested solutions:

/* TODO: suggested solution sources */

Chapter links

Vimeo channel

Source code

  • Github [TODO: repository]

Books this chapter is a part of

Further reading

TODO: links here

  • []
  • []
  • []
  • []
  • []
  • []
  • []

Book TOC | previous chapter | TODO: next