Purpose of Implementing the Observer Pattern

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


--
Regards,
Mohamed Mansour
Microsoft Student Partner

Re: Purpose of Implementing the Observer Pattern

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!
|
*************************************************
"Mohamed Mansour" wrote in message
news:5D67FFA2-D0F5-4748-B09B-45A3573280A8@microsoft.com...
> 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
>
>
> --
> Regards,
> Mohamed Mansour
> Microsoft Student Partner

Re: Purpose of Implementing the Observer Pattern

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)" wrote in
message news:umvLGmlQIHA.5264@TK2MSFTNGP02.phx.gbl...
> 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! |
> *************************************************
> "Mohamed Mansour" wrote in message
> news:5D67FFA2-D0F5-4748-B09B-45A3573280A8@microsoft.com...
>> 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
>>
>>
>> --
>> Regards,
>> Mohamed Mansour
>> Microsoft Student Partner
>
>

Re: Purpose of Implementing the Observer Pattern

"Mohamed Mansour" wrote in message
news:5D67FFA2-D0F5-4748-B09B-45A3573280A8@microsoft.com...
> 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.

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.
--
------------------------------------------------------------ --------------------
John Saunders | MVP - Windows Server System - Connected System Developer

Re: Purpose of Implementing the Observer Pattern

I would say the same thing. And phrase it this way.

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




"John Saunders [MVP]" wrote in message
news:u8DTUUnQIHA.4476@TK2MSFTNGP06.phx.gbl...
> "Mohamed Mansour" wrote in message
> news:5D67FFA2-D0F5-4748-B09B-45A3573280A8@microsoft.com...
>> 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.
>
> 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.
> --
> ------------------------------------------------------------ --------------------
> John Saunders | MVP - Windows Server System - Connected System Developer
>
>