Getting away from Console apps and Console paraphernalia, “Scenario C” is all about how top-level code can plug in to more interesting orchestrations.
Here’s a quick 5-minute video showing off top-level code forming the body of a game loop:
I really wanted to re-create the simplicity of my earliest experiments with animation and writing very primitive games in (you guessed it) Qbasic. So I pushed all of boilerplate into a base class in a library and now this one file can accomplish more just based on how the base class decides to run it; it’s pseudo-scripting. A great use of inversion-of-control in action 😊
And this same approach can be used to solve other problems too, depending on your style. Sometimes have situations where a class is dominated by one (or a few) very important methods that maintainers should focus on, particularly in derived types. Does this happen to you and if so, how do you highlight that? Do you just put a comment over it that says
' Keep this method at the top or do you put it in a separate partial file?
I really wanted to do something fun and not-console centric with this scenario. In my next scenario I’m going to expand on this approach to do something even cooler (and remote from Console apps) so look out!
Feedback welcome, please share, thanks!
P.S. Reminder: This is Scenario C. It’s the third of 5. I’ll post the usual GitHub issue with my writeup of all the design details/questions I ran into at a future date.