Sheepolution wrote:I felt like I was making it more complicated for myself for the sake of doing it "the right way"
Why do you feel like it's more complicated? You're talking about one extra "return" per module, and one extra "require" per dependency. In return for that, you get no namespace pollution and no chance of name collisions, no ambiguity about what things are or where they came from, a clear picture of what your dependency graph looks like, clear indicators of overly tight coupling, modular testability, increased code comprehension / predictability, and so on.
If you want to cut corners in your own code, nobody can stop you, but consider that doing that in a
tutorial for beginners may be doing your audience a disservice, given that (by your own words) this is
not "the right way" to do things. Whether this kind of indiscriminate use of globals is good or bad design shouldn't even be a debate, it is bad design, and it encourages more bad design, hands down. You don't have to take my word for it, you can read pretty much any article on the subject and it will come to the same conclusion.
The only reason I chose to say something about it here is because encapsulation is generally considered to be one of the core tenets of OOP, and the irony of using globals over encapsulation in a tutorial about classes was just too hard for me to ignore.
Sheepolution wrote:I don't think it's something I should be teaching so soon.
It might not be something you need to teach at all, just lead by example; if your viewers want to cut corners with globals instead, let them work that out for themselves.