Timeline for Dealing with an often occuring dependency that is not related to the class
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 3, 2014 at 8:25 | comment | added | RJD22 | After some discussion I came to the conclusion that you just have to add the dependency to every view. I might not like it but sadly it's a fact I have to accept. That is why I gave you the +1 and correct answer. | |
| Apr 3, 2014 at 8:24 | vote | accept | RJD22 | ||
| Apr 1, 2014 at 12:49 | comment | added | George Howarth | Unfortunately, I think in any case you won't be able to have your cake and eat it too due to the nature of the problem you describe; you will need to make a trade-off at some point. Off the top of my head, a second option would be to define a "BaseView" and declare a property into which you can inject a dependency, but that would have its own problem in that the dependency would be seen as optional. A third option would be to obtain the dependency through a static member of another class via a common factory method (so you can unit test it). | |
| Apr 1, 2014 at 11:42 | comment | added | RJD22 | But what if the dependency needs to be used in almost every View class? It really seems wrong to add it as a dependency to every constructor. | |
| Apr 1, 2014 at 11:36 | review | First posts | |||
| Apr 1, 2014 at 11:38 | |||||
| Apr 1, 2014 at 11:17 | history | answered | George Howarth | CC BY-SA 3.0 |