Observer pattern

[PaulStat]

A quick question about this pattern can something be both the subject and an observer itself? If so is this advisable?

Imagine the scenario:

You have a user interface with a load of text fields, these text fields are populated by the UI's associated file input stream. This input stream has a list of sections (observers of the file).

If an update happens to the UI both the file and it's associated sections will need to be updated.

So by my reckoning the input stream will be being observed by it's subscribed sections and it will also be observing the UI itself.

 

[ByteJuggler]

Yes it is possible and sometimes very useful and/or required. But, be very careful to have a firm grasp on where each object lives (in what layer, if you like) and thus who its observing and who it's observed by. Ideally you should try to avoid loops in the object graph, otherwise you'll have to start dealing with situation where A notifies B, which notifies C, which in turn notifies A etc. If your system is layered you can sometimes either completely avoid this type of situation by keeping your relationships going one way, or if not avoid it, at least limit the number of loops int he notification graph and keep them under careful control. The important thing is to think through who registers/observes who so that you can keep a control on the consequences.

In your example, you might consider (if I understand you correctly) have the "sections" as, in effect, a layer between the actual file and the UI. Then the UI only observes the Sections, and the sections are responsible for updating the file and notifying other registered (observing) UI elements. You could conceivably even have the sections observe some observable version of the filestream, so that if it's updated, the section(s) will be notified, which in turn will notify the UI to update itself. In this scenario, your sections will then therefore be both observers and subjects, observing the filestream, and being observed by the UI.

I would probably not have the sections observe the UI also as you seem to be suggesting, as that would cause a loop in the notification graph. After all, when the user interface is clicked or changed in some way, the UI can actively tell the appropriate section whats changed/update the appropriate section. The section can then update the file, and/or notify any other (UI) observers which will update the UI again.

Hope that helps.

 

[PaulStat]

You could conceivably even have the sections observe some observable version of the filestream, so that if it's updated, the section(s) will be notified, which in turn will notify the UI to update itself. In this scenario, your sections will then therefore be both observers and subjects, observing the filestream, and being observed by the UI.

Thanks BJ that clarifies a few things for me. I may have more questions after my brain has absorbed all this information properly

 

[ByteJuggler]

Thanks BJ that clarifies a few things for me. I may have more questions after my brain has absorbed all this information properly

OK no worries.

Just a sidenote about "loops in the notification graph" again: Sometimes they are neccesary/acceptable so it's not that you should neccesarily "avoid at all costs." The point I'm trying to make thought is that you should try to anticipate when you end up with a possible notification loop, so that when it happens, you can deliberately deal with it up front and put some measures in place to prevent an infinite loop or out of control notification "storm". Obviously, if your design is simple enough to avoid loops outright, then life is simpler, is all.