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:
- The event arrives, but only sets a flag, which the majority of the program polls (Really? Yes, really.)
- 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.