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
