observers, drawbacks & alternative
hey..I need to make a report about design patterns and observers. I need to speak about avantages, drawbacks (for the two one) and i have to find an alternative to observers. I already done avantages about design patterns and observer but i do not manage to find real drawbacks of observers. And i always wonder which alternative approach i could discuss..
thks a lot if u can help m..really thanks..
best regards !Jul
> hey..I need to make a report about design patterns
> and observers. I need to speak about avantages,
> drawbacks (for the two one) and i have to find an
> alternative to observers. I already done avantages
> about design patterns and observer but i do not
> manage to find real drawbacks of observers. And i
> always wonder which alternative approach i could
> discuss..
> thks a lot if u can help m..really thanks..
> best regards !Jul
Answering that question is somewhat dependent on the context in which you are using the Observer pattern. There are some common pitfalls I've seen with a "plain" Observer pattern:
1. Unexpected updates. An observer generally has no knowledge of the subject's implementation. It may mutate the subject and cause another update unintentionally leading to undesired behavior.
2. Endless loops. An update causes observer A to mutate the subject which causes an unexpected update that causes observer B to mutate the subject which causes an unexpected update which causes observer A to mutate the subject ad infinitum.Obviously, directly related to the first pitfall.
3. Unspecific updates. Though it certainly is possible to be specific about the update I believe that the "vanilla" Observer pattern is one in which there is not necessarily any information passed as to what changed, just that the subject's state changed in some way. This can be a huge drawback as a change in the subject's state may necessitate a great deal of computational time for the observers to update themselves. There are a great many ways to work around this and still use the observer pattern such as delivering a "payload" of some sort to indicate the change but all of these produce an added level of complexity to the code. This is part of the observers being decoupled from the subject which is of course probably the most significant reason to use the pattern in the first place. It is a double edged sword.
As for alternatives, I think that really is dependent upon the requirements you're attempting to meet with the pattern in the first place. In cases where the Observer pattern is being used to facilitate communication between objects that don't necessarily have any knowledge of each other the Command pattern might be a viable alternative.
There are 2 very basic alternatives:
1. Just do what the observable does but without the interface: Add the interested object to the data object likely to change and when the data object receives calls to methods that change it's data call a method on the interested object to let it know.
2. Write a loop to continuously check to see if the data has changed. The advantage of this is that the data need not know that anything is "watching" it. The disadvantages are obvious.
Ken_Sa at 2007-7-16 21:11:30 >
