2

Quick example:

  • HM observes CM
  • SM observes CM
  • HSM observes HM and SM, but wants to be updated only after both have their new value derived from CM.

More detail:

(this is still a made-up example, but the closest and simplest I can come up with)

class ColorModel:

  • can store any RGB color.
  • observable by a ColorObserverInterface object.

class HueModel implements ColorModelObserverInterface

  • can store the hue value derived from an RGB color.
  • observes a ColorModel object to update its hue value.
  • observable by a HueObserverInterface object.
  • observers are notified only if the hue has actually changed.

class SaturationModel implements ColorObserverInterface

  • can store the saturation value derived from an RGB color.
  • observes a ColorModel object to update its saturation value.
  • observable by a SaturationObserverInterface.
  • observers are notified only if the saturation has actually changed.

class HueSaturationMonitor implements HueObserverInterface, SaturationObserverInterface

  • display a point whose x-coordinate represents the hue, and the y-coordinate represents the saturation.
  • observes a HueObserver object and a SaturationObserver object.

Problems:

  • Whenever the color in ColorModel changes, up to two updates are triggered on the HueSaturationMonitor object.
  • in case that the new color has the same saturation as before, only the hue update triggers - and vice versa.
  • The order in which the two updates trigger depends on the subscription order of the two observers on the ColorModel.
  • There is going to be an intermediate state when the x-coordinate of the HueSaturationMonitor is already on the new value, while the y-coordinate is still on the old value, because only one of the two updates has triggered yet. For the sake of the example, let's assume that any such intermediate state of the HueSaturationMonitor is undesirable, and we want to switch directly to the final x/y position.
  • The HueSaturationMonitor can only function correctly if both HueModel and SaturationModel are subscribed to the same ColorModel. There is no way to enforce that from within the HueSaturationModel.

Question:

How can I organize interdependent observers, without depending too much on the order in which they are subscribed to each other? How could I delay a trigger until all sources are updated?

Why is this not a duplicate?

There are other questions that deal with multiple observers and observables plugged together to form a network. This network can be drawn as a directed graph.

The distinctive feature of this question is in the nature and topology of this network / the graph:

  • The HueSaturationMonitor observes two observables, and its behavior depends on the combined values of both observables. Most other questions have observers that observe only one thing, or where the values from the two observables don't need to be combined.
  • The directed graph we are dealing with is acyclic, BUT if you ignore the direction then it becomes cyclic. This is part of the challenge in this question. The directed graph represents a partially ordered set, but not a tree.
  • The directed graph contains directed chains with length > 1, which means there is a two-level dependency. E.g. HSM observes HS observes CM.

Some of these characteristics appear in other questions too, but it is their combination that is relevant and that causes the problem I want to solve.

  • Do you really need multiple classes? Isn't one or two classes enough? – Euphoric Apr 21 '14 at 19:36
  • "need" is a harsh word.. The original use case (which is not published here) has good reasons for separate classes. And even if it wouldn't, I really want to know how I could plug this together if I want to. – donquixote Apr 21 '14 at 19:44
  • For the existing example, let's assume that we want HueSaturationMonitor to be a dumb thing that does not know what a color is, but that can observe two float values x and y. these could be derived from a color or be something totally different. – donquixote Apr 21 '14 at 19:45
  • 1
    @CorbinMarch I found this and other questions while writing this, but decided that none of them is asking what I want to know. They are related but different questions. They all deal with observer dependency graphs, but the structure of these graphs is different. – donquixote Apr 21 '14 at 21:32
  • 2
    @donquixote - please edit into your question why you feel the suggested duplicate isn't a good match. Preferably add a detail or two that calls out the difference. I'm voting to leave your question open. – GlenH7 Apr 22 '14 at 0:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.