I have several services that implement an observer interface and one service that implements the corresponding observable interface.

I'm currently using unity together with Prism so I would prefer to keep this combination. My current solution is to inject the observable service in the observer services and let the observers subscribe themselves. I'm not sure this is a good design since the observer doesn't really depend on the observable.

Is there a way to automatically couple these using a dependency injection container? Is there another way?

  • I don't know about unity and Prism, In Spring you could use the "afterPropertySet" in order to run some extra configuration code, like adding the observer to the observables. This permit to not have to centralize all your observer declaration. – Walfrat Jun 30 '17 at 7:25
  • No familiar with Spring. In the documentation I read about factories, not sure how that connects to my issue with services. – Jef Patat Jun 30 '17 at 8:13
  • Well, what you could do, is to inject your observable in your observer and in the constructor, add the observable to the observer. For that you need to use construcot injection, not setter based. – Walfrat Jun 30 '17 at 8:18
  • That's my current solution in my question. Second paragraph, with an argument why I do not like it. – Jef Patat Jun 30 '17 at 8:38
  • If all of your observables implements a common "Observable" interface, you could just inject to your observer the list of "Observable" that they have to observe. Which avoid an hard coupling between the classes. I might have others Spring based solution but they're probably too much for this. – Walfrat Jun 30 '17 at 9:07
up vote 3 down vote accepted

The benefit of your current design is that the observers can control WHEN they are observing. When an observer wants to start observing it registers (or subscribes if you like) with the observed object (subject) by calling a register method and passing a reference to itself.

Within observer:

subject.register(this)

later

subject.unregister(this)

You're worried about this creating an unneeded dependency. The only dependency here is on the subject interface that ensures their are register and unregister methods to call. Oh, and you need a reference to the subject.

So it isn't so much a question of dependency. It's a question of whether you want your observers to be responsible for deciding when they observe.

If you don't want your observers to be responsible for deciding when they observe you need some 3rd thing that will take on that responsibility.

It is possible to provide the subject with it's list of observers when building the object graph. You'll either need to call a setter on the subject over and over, call a constructor that takes a variable number of args, or pass it a collection of observers.

If your DI container can do any of those then it can be your "some 3rd thing". If not you might need to write construction code that acts as the "some 3rd thing".

  • "So it isn't so much a question of dependency. It's a question of whether you want your observers to be responsible for deciding when they observe." That was the missing piece in my thinking. Thx. – Jef Patat Jun 30 '17 at 10:46

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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