I would really like to see an example too. It seems to me that the shorter of the two lists of methods is just going to be either class A or class B itself.
I've reached this from a different direction; when I've had a difficult service to test, I've split it into two cooperating services that can each be tested on their own.
HiveMind and T5 IoC are capable of co-injecting (via constructors) services; this is because what gets injected is a proxy. You'd have a problem trying to inject service implementation A into service implemenation B and vice versa at the same time, but with proxies, theres the extra abstraction.
An example of this (that I used on my blog): Circular dependencies between classes can be solved by introducing a new class, e.g., if classes 'Alice' and 'Bob' has references to each other for exchanging messages, then a class 'Channel' should be introduced that they both will use to send and receive messages.
Hi Misko, What kind of class would you make to resolve the circular dependency introduced by applying DI to the MVP pattern? Currently I'm manually injecting the view, inside the view's ctor, into a 'View' property in the presenter, which is ugly. Now I have to remember every time I make a new implementation of this view to set the presenter's View property. I could use a DI framework to automatically inject the property--assuming I set the View implementation to be a singleton in binding configuration (else it would try to inject a brand new view, which puts me right back where I started). There's got to be a better way, though. Maybe a better View-Presenter design?
Could you post a small example?
ReplyDeleteWhat about circular references involving several classes. How do you apply your rule in these (more typical) cases?
ReplyDeleteI would really like to see an example too. It seems to me that the shorter of the two lists of methods is just going to be either class A or class B itself.
ReplyDeleteIs it supposed to be a list of methods in the class that reference the other object?
ReplyDeleteCan I just AOL the example request. I'm a little confused by what you mean by this.
ReplyDeleteAlso why would this be any harder to test than any other complex required dependency? Mock or stub the injected instance.
Really enjoying your posts Miško, each one makes me think :)
ReplyDeleteI've reached this from a different direction; when I've had a difficult service to test, I've split it into two cooperating services that can each be tested on their own.
ReplyDeleteHiveMind and T5 IoC are capable of co-injecting (via constructors) services; this is because what gets injected is a proxy. You'd have a problem trying to inject service implementation A into service implemenation B and vice versa at the same time, but with proxies, theres the extra abstraction.
Anyway, the mantra is: "Small is Beautiful".
An example of this (that I used on my blog):
ReplyDeleteCircular dependencies between classes can be solved by introducing a new class, e.g., if classes 'Alice' and 'Bob' has references to each other for exchanging messages, then a class 'Channel' should be introduced that they both will use to send and receive messages.
Hi Misko,
ReplyDeleteWhat kind of class would you make to resolve the circular dependency introduced by applying DI to the MVP pattern? Currently I'm manually injecting the view, inside the view's ctor, into a 'View' property in the presenter, which is ugly. Now I have to remember every time I make a new implementation of this view to set the presenter's View property. I could use a DI framework to automatically inject the property--assuming I set the View implementation to be a singleton in binding configuration (else it would try to inject a brand new view, which puts me right back where I started). There's got to be a better way, though. Maybe a better View-Presenter design?