Purpose of Implementing the Observer Pattern

  • Thread starter Thread starter Mohamed Mansour
  • Start date Start date
M

Mohamed Mansour

Hello,

What is the purpose of implementing the Observer Pattern if we can trigger
an event easily?

For example (from books),
You have a "Forecaster" which notifies "Observable" when a prediction is
ready, then there is a "WeatherViewer" which calls methods from the
"Observer Interface".

What is the point of implementing the Observer Pattern, we could have just
make and fire off an Custom Event stating "PredictionReadyEvent".

Can someone tell me what the point of using this Gang of For pattern in
..NET. Maybe I am just misinterpreting it.

Thanks
 
The question is "who is driving"?

If you are setting up software where the item which would be observed is the
driver, then there is no reason to have the observer pattern. If, instead,
you are setting up a less "aware" object, then the observer works.

Okay, here is a shot. In OOP, you generally end up with two types of objects
on your business layer. The first are state objects, the other are behavior
objects. State objects hold state, or serve as "data" models. For example, a
customer object contains the name, address, phone, etc. of a customer.
Behavior objects do work.

While you do see some systems designed where the customer object is aware of
the data contracts, this is generally a mistake. It is generally better to
have another object fill, update, save, etc. (proxy the CRUD for the
object).

Following this generality, if you have a state object that you want to watch
changes in state, you can either add an event (add behavior to a state
object) or add a piece that watches the object (place behavior in a behavior
object).

Now, let's imagine our cutomer object and we want to know some type of
change in state. I can have the object load up and fire off an event. But,
if I do this, the object is handling both state and behavior. There is
nothing inherently wrong with this, but it does cloud intent, which will
generally make my solution less maintainable. My other option is to have
another object watch for the state change.

Probably not the best examples, but I am flying by the seat of my pants.
Hopefully, however, the idea of intent in code and the generality of
separating state and behavior will give you enough of a base to work with.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
Thank you Gregory :) Very well explained !

I can now see many situations where implementing the observable pattern
would better than firing off a simple event.

Thanks! Much appreciated!

--
Regards,
Mohamed Mansour
Microsoft Student Partner

Cowboy (Gregory A. Beamer) said:
The question is "who is driving"?

If you are setting up software where the item which would be observed is
the driver, then there is no reason to have the observer pattern. If,
instead, you are setting up a less "aware" object, then the observer
works.

Okay, here is a shot. In OOP, you generally end up with two types of
objects on your business layer. The first are state objects, the other are
behavior objects. State objects hold state, or serve as "data" models. For
example, a customer object contains the name, address, phone, etc. of a
customer. Behavior objects do work.

While you do see some systems designed where the customer object is aware
of the data contracts, this is generally a mistake. It is generally better
to have another object fill, update, save, etc. (proxy the CRUD for the
object).

Following this generality, if you have a state object that you want to
watch changes in state, you can either add an event (add behavior to a
state object) or add a piece that watches the object (place behavior in a
behavior object).

Now, let's imagine our cutomer object and we want to know some type of
change in state. I can have the object load up and fire off an event. But,
if I do this, the object is handling both state and behavior. There is
nothing inherently wrong with this, but it does cloud intent, which will
generally make my solution less maintainable. My other option is to have
another object watch for the state change.

Probably not the best examples, but I am flying by the seat of my pants.
Hopefully, however, the idea of intent in code and the generality of
separating state and behavior will give you enough of a base to work with.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box! |
*************************************************
Click to expand...
 
Mohamed Mansour said:
Hello,

What is the purpose of implementing the Observer Pattern if we can trigger
an event easily?

For example (from books),
You have a "Forecaster" which notifies "Observable" when a prediction is
ready, then there is a "WeatherViewer" which calls methods from the
"Observer Interface".

What is the point of implementing the Observer Pattern, we could have just
make and fire off an Custom Event stating "PredictionReadyEvent".

Can someone tell me what the point of using this Gang of For pattern in
.NET. Maybe I am just misinterpreting it.
Click to expand...

I believe that events in .NET already implement most, if not all, of what
the GoF Observer pattern is for. They separate the object being observed
from the objects observing it.
 
I would say the same thing. And phrase it this way.

..Net framework kinda has a "built in" observer pattern setup...with events
raising.
 
Back
Top