3

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?

Improve this question
5
  • 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, 2017 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, 2017 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, 2017 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, 2017 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, 2017 at 9:07

1 Answer 1

Reset to default
6

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. The observer doesn't even need to know the subjects type.

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".

Improve this answer
1
  • 1
    "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, 2017 at 10:46

Your Answer

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

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