By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,561 Members | 3,113 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,561 IT Pros & Developers. It's quick & easy.

Purpose of Implementing the Observer Pattern

P: n/a
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

Dec 19 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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" <m0@community.nospamwrote in message
news:5D**********************************@microsof t.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

Dec 19 '07 #2

P: n/a
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)" <No************@comcast.netNoSpamMwrote in
message news:um**************@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" <m0@community.nospamwrote in message
news:5D**********************************@microsof t.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

Dec 19 '07 #3

P: n/a
"Mohamed Mansour" <m0@community.nospamwrote in message
news:5D**********************************@microsof t.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
Dec 19 '07 #4

P: n/a
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]" <john.saunders at trizetto.comwrote in message
news:u8**************@TK2MSFTNGP06.phx.gbl...
"Mohamed Mansour" <m0@community.nospamwrote in message
news:5D**********************************@microsof t.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


Dec 27 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.