On Fri, Jan 3, 2014 at 9:03 AM, spir <denis.s...@gmail.com> wrote:
> On 01/03/2014 12:41 PM, Alan Gauld wrote:
>
>>
>> return [step, self.move_count, self.num_chutes,
>>> self.num_ladders, self.chutes_list, self.ladders_list]
>>>
>>
>> In OOP you rarely have to return attributes. And since step
>> is passed in as an argument the caller already knows [it]. So I
>>
>> don't think you really need to return anything here.
>>
>
Alas, it's uglier than all that, and probably inherently non-OOP organized.
The calling method DOES know the step variable (attribute? it's not part of
a class, is it still an attribute?), since it's using it to iterate through
a list: but that variable is gone by the time the play_game returns, and
yet I want to ensconce it in the data structure to keep track of the
different games... And so I pass it in to save it to the data structure.
It's ugly, and probably not the right way to do that (post script: I think
I figured this out below).
Calling method:
return [self.play_game(i) for i in range(gamecount1)]
def play_game(self, step):
# various stuff happens, but step is just passed through to be
stored in the structure that the calling method is contributing to
return [step, self.move_count, self.num_chutes, self.num_ladders,
self.chutes_list, self.ladders_list]
> Maybe the intent here (except from the case of step) is to conceptually
> isolate another part of code from the current object (here a 'game'), or
> from this method (play_game). So that don't they interact in a hidden way
> (that one cannot guess from the outside, without reading code in detail).
> In other words, to make code _transparent_, which is indeed a common advice
> (and one I approve).
>
> In this, to have the caller explicitely, obviously read information about
> the 'game' object, one could just:
> return self
>
> However, this makes no sense if the caller the cirrent method, play_game,
> is another method of the 'game' ;-). In this case, indeed return nothing.
>
> (All this, if I correctly understand and interpret.)
>
> Denis
Well, I sort of mangle OOP still. Here's the issue: I have this play_game
method of Game, which returns/fills in the "results" of a game in the form
of a list of ints & lists. What I though I want is to play lots of games,
gather all those game "results" into a big array (just another list really,
of course), and then do stats/analsis on that array. But I think my
thinking is broken here: I am trying to create a list of game results,
whereas I should be creating a list of games (with their corresponding
attributes)... And that should happen altogether outside the Game glass. I
imagine I should have another class for that, say GameArray... but that's
just a first thought on the next reorganization...
So I guess my Game class should have an attribute like game_number,
corresponding to step variable above, and GameArray should do something
like...
game1 = Game() # instance of Game
for i in range(gamecount): game_array[i] = game1.play_game(i)
(inside play_game: self.game_number = i)
And I guess GameArray can hold all the stats/analysis/printing functions,
since that's the object they operate on...
This sounds like the right direction here, but I don't completely trust my
own thinking yet on this stuff. In retrospect, my need for a reset method
probably indicated I was going the wrong direction, and probably popped up
as soon as I tried to deal with a multitude of games within the Game class
itself.
thanks as always!
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
