A talk about observer pattern [closed]

Question

As part of a university course I'm taking, I have to hold a 10 minute talk about the observer pattern. So far these are my points:

• What is it? (defenition)
• Polling is an alternative
• Polling VS Observer
• When Observer is better
• When Polling is better (taken from here)
• A statement that Mediator pattern is worth checking out. (I won't have time to cover it in 10 minutes)

I would be happy to hear about:

• Any suggestions to add something?
• Another alternative (if exists)

Answer 1

Since much has been said already, heres other three things I thought whoever using a design pattern would also be interested on knowing in advance:

• How hard is it to understand/implement? (hey! someone already said it doesn't add much in this small question! Maybe the trade-off is not worth? Maybe showing a 15 sec diagram showing a frustrated person trying to implement it or trying to learn it could be cool for a different point of view). Also, on book reviews I have read design patterns are hard to understand from the book (head first was actually complimented for making it easier for beginners).
• How hard is it to identify it? Abstract Factory usually screams on your face. What about this one? Knowing easily which design pattern is on the code saves you considerable time on understanding the code :) (Oh hey! Thats design pattern xx!). Is the observer easier to observe?
• How well does it goes along with other patterns? Some design patterns are harder to go well than others!

These are things I would look on to just point a chart, a picture or maybe even bringing up as of you did care about these points. I think SEI- Carnegie Mellon has technical reports about related points, and certainly the literature is full of attempts to analyze this. I agree with the other answers, but I also like considering this when Im looking into one.

Answer 2

I would focus the talk on any pattern on the two questions:

1. What problem does it solve?
2. What drawbacks does it have / what's the cost?

Answer 3

IMHO lots of people talk about patterns, but don't seem to add much. I can read faster than I can listen, and I can skim to the interesting points in a book or paper.

So, of you have time, try to think about some more interesting ways to get at the issues, which might stimulate your audience to engage more areas of their brains.

Consider applications or uses where, for example, polling might be better than 'observer', to highlight the differences in more novel ways.

A scenario: a program could poll the state of a button (on a toaster) looking for a change, or the button's state could be 'observed' and an event could tell the observer that the button has changed (e.g. due to an interrupt).

A polling program can look at the button state when it needs to know, and at a rate that suits its purpose. It can have predictability. It is straightforward to test. It may even be straightforward to prove 'correct'.

An event driven (interrupt) program has several tactics, for example:

1. The event arrives, but only sets a flag, which the majority of the program polls (Really? Yes, really.)
2. The event arrives and is immediately acted on. Now we need to ensure:
   a. events don't arrive too quickly, and
   b. an earlier event was fully handled before starting on this one.

So the program might ignore new events until it finishes handling the current event! [Ask the audience: what are the alternatives?]

Further, if there is more than one thing to observe, and observers interact, you might need to define some mechanisms to ensure the sequence of actions due to events is valid.

This is usually harder to test, likely harder to prove, and is likely non-deterministic, making bug reports harder to verify, investigate and fix.

Summary: more powerful mechanisms are not 'for free', and it may be more helpful to encourage your audience to critically analyse the costs rather than focus only on the benefits.

Answer 4

What is it? (defenition)
When you want to observe something, a change in an object to notify other objects you can use this.
All the event system in programming languages are based on this logic.

Polling is an alternative
Performance would be really bad. Really really bad. Observer is a little more complicated but does not consume your resources.

Polling VS Observer
Polling: Checking continuously the change, resource intensive
Observer: Smart way to use interfaces to keep track of changes by notifications.

When Observer is better
Most of the time.

When Polling is better (taken from here)
When you don't have to implement and test observer code and you really don't care about the performance. Also when you don't want any unintended bugs due to less time of testing. In addition when you really want to conform OOP principles. Some say observer regulates some OOP principles.

Any suggestions to add something?
It is simply using interfaces to run a notification method. It is like this:

mainObj.notifyThis(otherObj1);
mainObj.notifyThis(otherObj2);
//Minor objects implements an interface by your design which has let's say "notify()" method

//When something happens in mainObj it runs
For every notification objects AS o
o.notify();

Another alternative
Workflow logic, which will be far more complicated.

What problem does it solve?
It solves the performance problem of polling

What drawbacks does it have / what's the cost?
More complicated design and which means more possible bugs, and some regulated OOP principles

Answer 5

I would add that quite few (if not majority) of architectural patterns (MVC, MVP, MVVM come to mind) utilize it rather heavily. Not to mention, it's built into Microsoft .NET framework via events system - few points to highlight its importance and widespread.

Answer 6

I would also add a few things about the situation when the observed object and the observer object exist on different systems. It may be a lot for a 10 minutes talk, but it's a more interesting situation about this pattern than the usual things your audience is used with.