Timeline for Reaching back up into the parent class
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 13, 2016 at 10:31 | comment | added | Roger Heathcote | Update: I did that. The child classes are now passed optional callbacks for each event which might cause a state change. I am much happier with that solution as the children don't have to know about the wider system state or any of the parent's methods/state. | |
| Sep 29, 2016 at 8:44 | comment | added | Roger Heathcote | Thanks for the updated answer, I agree adding methods to the parent is the way forward. Was thinking of going one step further and passing these into the other classes as callbacks to be called as needed, rather than having the children need to know about a method name in the parent class. | |
| Sep 27, 2016 at 14:21 | history | edited | mcknz | CC BY-SA 3.0 | added examples |
| Sep 27, 2016 at 10:08 | comment | added | Roger Heathcote | The RecorderApp class implements a state pattern, the final state of which needs to reset the app to it's initial state, I don't see how I can do this if the other classes are instantiated outside this class and passed in :/ Also I don't see how instantiating them outside helps me make them talk to each other. Sorry if I'm being slow here, fairly new to JS and design patterns. | |
| Sep 26, 2016 at 23:18 | history | answered | mcknz | CC BY-SA 3.0 |