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.
