You are absolutely correct that this is about OOP design. And I did consider which list to post this question to.
But as the question deals with practices that relate to implementing Pygame games, I thought that members of this list would have the exact experience and background needed to answer the question. Further, since I am building and teaching a course using Pygame, I want to ensure that I am explaining code in a way that would allow my students to write Pygame applications cleanly. Irv > On May 26, 2019, at 1:19 AM, Pascal Schuppli <pschup...@phar.ch> wrote: > > I don't mean to sound like a list police officer, but your question isn't > really specific to pygame, it's about OOP design and small-scale design > decisions. IMO, you should be posting it on a site like > https://cseducators.stackexchange.com/ instead. > > On 26.05.19 07:00, Irv Kalb wrote: >> Thanks for the comments. Yes, there are many more variables than just the >> score. I just wanted to show one simple example to make the problem >> understandable. >> >> I hadn't thought of the extra "Session" object, it sounds like an >> interesting approach. However, I'm looking for a clear solution that I can >> teach to students who are just learning about OOP. So, adding the extra >> layer would make things too complicated for my students. Unless someone has >> a better approach, I will probably just use the approach of setting these >> variables to None in the __init__ and the real value in the reset method. >> >> Thanks, >> >> Irv >> >> >>> On May 25, 2019, at 5:26 PM, mar...@protonmail.ch wrote: >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Saturday, May 25, 2019 8:55 PM, mspaintmaes...@gmail.com >>> <mspaintmaes...@gmail.com> wrote: >>> >>>> For just a score variable, it's probably not a big deal to have an = 0 in >>>> there twice as duplicate code, but games are complicated and so I'm sure >>>> you've got lots of other fields as well, and that's where the duplication >>>> becomes problematic, especially if it's just there to appease the linter. >>>> I'm assuming the Game object is sort of an application context that >>>> survives the entire duration of the program's runtime, and that aside from >>>> score, you have a variety of other fields as well that need to be reset. >>>> For things like this, I would split game into a 2-tiered object, where >>>> each object has the desired lifespan. Something like this... >>>> >>>> class ApplicationContext: >>>> def __init__(self): >>>> self.session = GameSession() >>>> >>>> def reset(self): >>>> self.session = GameSession() >>>> >>>> class GameSession: >>>> def __init__(self): >>>> self.score = 0 >>>> self.player_location = (0, 0) >>>> self.zombies = self.build_zombie_list() >>>> self.im_just_making_up_examples = etc >>>> >>> This looks like a possible solution, but I would advise against it. I've >>> gone there a couple times I guess, and I ended up throwing away code that >>> looked like this every time. Your `Game` can perfectly well deal with state >>> itself. If you start writing state-holder objects, you'll create more work >>> for yourself down the line. You'll think about it and then you're likely >>> going to transparently proxy `GameSession` into `Game` using >>> `__getattr__()`, and maybe even `__setattr__()` methods. Why, then, pretend >>> you were dealing with attributes of your `Game` instance when you could and >>> should just do that? >>> >>> I think the best solution would be setting `self.score = None` in >>> `__init__` and having it set to a proper value by .reset(). But I do admit >>> that I'd probably type the line only to shut up a linter and not for any >>> real purpose. >>> >>> cheers! >>> mar77i >>> >>> >>> Sent with ProtonMail Secure Email. >>> >>> >
