Timeline for How to avoid DI dependency cycle for observer pattern
Current License: CC BY-SA 4.0
6 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 10, 2020 at 20:03 | comment | added | candied_orange | @C-Otto it is the issue if you want construction code to establish it. Setter injection can but constructors can’t. | |
May 10, 2020 at 19:20 | comment | added | C-Otto | The observer has good reasons to have the transitive dependency (example: is notified about event "X for 123" and needs to create an event "X for 456"). However, the code that creates those events (the subject) does not need to know anything about the observers. So, no, I don't think the transitive dependency on the subject is the issue, although of course every edge on the cycle is part of the problem. | |
May 10, 2020 at 15:54 | comment | added | candied_orange | It’s you observer with the “transitive dependency on the subject” that’s spoiling your immutable fun. | |
May 10, 2020 at 15:50 | comment | added | candied_orange | I do too. But you physically can’t create cycles with constructors. It’s one of the reasons I like constructors. I’m not questioning the constructor. I’m questioning the cycle. You can’t be immutable with this stupid setter either. But none of this is fixed by adding a C. | |
May 10, 2020 at 15:44 | comment | added | C-Otto |
I prefer constructor injection over field/setter injection so that it is impossible to have cyclic dependencies. Why do you think it is a good idea to relax this requirement? I know that non-constructor injection (or maybe something like @Lazy ) would help.
|
|
May 10, 2020 at 15:34 | history | answered | candied_orange | CC BY-SA 4.0 |