Timeline for How to avoid a crazy amount of interfaces in UI with dependency injection?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2016 at 8:03 | comment | added | R. Schmitz | @scorpdaddy That sounds like the event system, just without events and with listeners instead. Well, that would also work. If you care to write that answer, I'll mark that as answered instead. Otherwise I'm gonna answer it myself tomorrow. | |
| May 2, 2016 at 15:58 | history | edited | Robert Harvey | CC BY-SA 3.0 |
edited body
|
| May 2, 2016 at 15:42 | history | edited | scorpdaddy | CC BY-SA 3.0 |
added 344 characters in body
|
| Apr 30, 2016 at 1:24 | comment | added | scorpdaddy | Would a DI Collection of "listeners for x" help. Widgets could access the collection and add themselves as listeners for x. Publishers could access the DI collection and publish to the collection. Instead of "passing" listeners - inject them. | |
| Apr 29, 2016 at 9:08 | comment | added | R. Schmitz | @Katana314 OK, well if you write an answer "use eventsystems" with a small explanation why that would remain testable, I'll mark it as answered. | |
| Apr 28, 2016 at 20:46 | comment | added | Katana314 | @R.Schmitz I certainly wasn't thinking of adding egregious interfaces to classes that won't need them. There are multiple event-handling systems I've dealt with that wouldn't have issues communicating from chidren to parents, ideally with no actual upwards referencing; but it's too much to describe in a comment. | |
| Apr 28, 2016 at 8:05 | comment | added | R. Schmitz | @Katana314 That sounds like a violation of the interface segregation principle to me, because I would have classes implementing several interface methods they do not need. Of course it might be that I'm following SOLID to religiously here. | |
| Apr 26, 2016 at 16:55 | comment | added | Katana314 |
@R.Schmitz And so as I understand it, in ChildOfChildOfChild, you might have a method that calls applicationInstance.OnItemAdded(item)? That could be something you could reorganize so that a child arbitrarily notifies "all 0-n listeners". You might have events that are broadcast to many areas that don't need them, but as long as listeners are easy to add, that's the main thing I think.
|
|
| Apr 26, 2016 at 16:04 | comment | added | R. Schmitz | @Katana314 For example, when an item is added, the 3dmodel needs to be updated and it does not belong in any of the product categories, so it is referenced in the application class, which listens to items being added/removed/changed. In the end that would pretty much be the same for every product category. Other UI parts also react (and listen), but the message needs to travel to the top because that's where the 3dmodel reference and the actual data (which is then also updated) is. | |
| Apr 26, 2016 at 15:55 | comment | added | R. Schmitz | @RobertHarvey No performance loss at all, it's only about readability. | |
| Apr 26, 2016 at 15:14 | comment | added | Katana314 | @R.Schmitz Can you elaborate on "passing on a lot of listeners"? Maybe my experience with DI in C# is low, but something tells me that wouldn't be necessary (at least in the constructor) with proper design. | |
| Apr 26, 2016 at 14:57 | comment | added | Robert Harvey | @R.Schmitz: Did the overhead matter? Was the UI sluggish, and was the design you described to blame? | |
| Apr 26, 2016 at 14:35 | comment | added | R. Schmitz | Sorry, "class hierarchy" was wrong wording here; it actually wasn't class hierarchy, but rather UI hierarchy. The 'widgets' are not subclasses of the application class, but the 'page' holds references to them in order to publish UI updates. It was very testable with this structure, but there was also a lot of overhead especially in the constructors, just passing on a lot of listeners for their (UI) children. | |
| Apr 26, 2016 at 13:14 | history | answered | scorpdaddy | CC BY-SA 3.0 |