The idea is that I have a set of properties that represent possible options in the app. These options can be modified through a variety of different ways, such as from the UI, remotely, third party, etc...

Each time one of these modifiers alters the state, the other modifiers need to be notified. E.g.: If the user marks a checkbox in the UI, the remote modifier and the third party need to be notified, so that they update their internal state.

There is no priority involved, and the state changes cannot be rejected. The only concern is to prevent the third party from receiving a notification when itself modifies the state.

Is there a good design pattern to solve these requirments?

  • What do you mean by "without a loop"? It's not clear in the text of your question. Commented Sep 13, 2014 at 16:01

1 Answer 1


The question is a bit vague (e.g. what exactly do you mean by a third party?), but to try and answer anyway:

I think you're looking for the Observer pattern. The intent of the pattern is to allow entities to be notified when the state of some object changes, while decoupling the two sides. I.e., the observers don't know anything about the subject except that it is observable, and the subject knows nothing about the observers except that they can be notified.

You can register all the modifiers as observers to your app (whatever part of it makes the most sense and is relevant to your situation: the GUI, the Model facade if you have one, etc...), and then you can send them a notification whenever the app's state changes, while keeping all of them decoupled and keeping things flexible.

Edit: If you're using the MVC pattern, then the Model class (more accurately the facade class to the backend system) is probably your Subject that the observers will listen to, because it stores the state of the app and can notify the observers when anything changes.

  • A third party is just an example of an object that may send changes to the state. By using the Observer pattern, the object that request the change will also get a notification of it, and that is what I want to avoid. Commented Sep 12, 2014 at 11:54
  • You can pass the sender object along with the observation notice. But ideally you should let it react to the message anyway - clicking a checkbox should send a message to your controller which in turn notifies all of its observers to update the ui. If some error occurs you don't want the checkbox checked if that is not the correct state.
    – DanDan
    Commented Sep 12, 2014 at 13:22
  • Not sure why you say "observers don't know anything about the subject except it is observable." This is not my understanding of the observer pattern. Observers surely DO know about subjects, and it's entirely OK to have that dependency. Observable as a class usually is provided to facilitate subscribing and unsubscribing functionality (it's reusable code, there's a list of observers, etc.). Commented Sep 13, 2014 at 14:26
  • @Fuhrmanator That depends on your implementation. Sometimes the observers do know about the subject and that's okay most of the time. However if a third party registers the observers to the subject (e.g. in MVC the controller might register the View to the Model to decouple the two), the observers don't have to know anything about the subject.
    – Aviv Cohn
    Commented Sep 13, 2014 at 14:31
  • Standard Observer (GoF) will notify all observers when a state changes, so you'd have to tweak the pattern to fulfill the requirement of prevent[ing] the third party from receiving a notification when itself modifies the state. Commented Sep 13, 2014 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.