Timeline for Reaching back up into the parent class
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 29, 2016 at 8:29 | comment | added | Roger Heathcote | @Dunk - Yes I thought it looked smelly, thanks for helping me clear it up. Happily I'm not stuck with this design, I'm rewriting an app I wrote quickly (and badly) a while back and trying to do a better job this time round. I'm very keen to reduce coupling in my code, but like most things worth doing it's easier said than done! | |
| Sep 27, 2016 at 19:52 | comment | added | Dunk | @technicalbloke - While many suggestions given by the people in Snowman's possible duplicate question implied otherwise. I 100% believe this to be a RULE, not just a suggestion unless you enjoy writing buggy and unmaintainable code. "Child classes should not know who contains them" Thus, calling back into the parent requires the child to know who contains them. That means the interpretation you wrote in your comment is a big NO. Your design is bad, but if you must use what you have then you are better off passing what each class needs to who needs it. e.g. AudioEngine to WaveFormDisplay. | |
| Sep 27, 2016 at 14:05 | vote | accept | Roger Heathcote | ||
| Sep 27, 2016 at 10:14 | comment | added | Roger Heathcote | Okay, adding a load of explicit methods sounds more convoluted to me in the short term but I'm totally happy to do it if it's a better architectural decision, I'm trying to up my programming game here, not get this thing working quickly :) So would making all communication go via methods in the parent class count as the mediator pattern? | |
| Sep 26, 2016 at 22:22 | review | First posts | |||
| Sep 28, 2016 at 17:21 | |||||
| Sep 26, 2016 at 22:20 | history | answered | Derrick Cheek | CC BY-SA 3.0 |