Hello Richard,

Thanks for your feedback and I hope you slept well and did not dream about this one.
And this exercise is exactly why I ask so many questions how I can make this work the OOP way.

Hopefully it's getting better with v3 where I heared the languages have more freedom to change challenges and test to make it more workable in the language you work with

Roelof



Op 24-9-2020 om 15:16 schreef Richard O'Keefe:
Since the problem can be solved, and has been solved, in programming languages that do not support object-oriented programming, there is obviously no unique "right" factoring of this problem into classes.  I'll be honest with you: this is the only Pharo exercism I have not tackled, and the reason is that I just found the problem specification too ugly to care about.  I had better get over that.

The two primary difficulties are
(a) the game is described one ROLL at a time, but scored one FRAME at a time.
(b) the rolls are recorded from past to future, but the score can only be
calculated from future to past.
The fact that there may be one extra roll at the end which is not technically
part of any of the 10 frames is just icing on the cake.

But this is *algorithmic* trickiness, not *world model* trickiness.

Let's imagine a Frame class.
- You get the first roll of the frame.  Fewer than 10 pins are knocked down.
  You cannot complete initialising the Frame yet.
- All 10 pins are knocked down.  You cannot determine the *score* of the
  frame yet.  This casts some doubt on the idea of the score being part
  of the state of the frame.  The score actually depends on the next two
  THROWS (rolls), not the next frame or the next two frames.  This casts
  much doubt on the idea of the concept "frame" being useful for the
  analysis.  At the very least, you will need to manipulate BOTH frames
  AND throws (rolls).
It looks as though a Frame class may just make things harder.
Since the only thing there is to know about a Throw is how many pins
were knocked down, it doesn't look as though a Throw class is much use
either.  This leaves us with a BowlingGame class that just keeps tracks
of rolls and then runs a moderately complex algorithm when it is asked
for the score.

Long past my bed-time or I would get stuck into it.

On Thu, 24 Sep 2020 at 23:53, Roelof Wobben via Pharo-users <pharo-users@lists.pharo.org> wrote:
Op 24-9-2020 om 13:42 schreef DavidBajger:
> Hi Roelof,
> I always wonder, what kind of answer you expect from your prior statement.
> To your question: "Can this plan be working or is there improvements to this
> plan." I can have this answer: Yes, it could be both: working or fail, but
> you don't know before you try.
>
> This exercise is a bit tricky:
> 1) I can recommend to use also LastFrame class, which has specific handling
> of bonuses in last round of game (subclass of Frame). Bowling game can be
> then initialized with array 9 Frame instances and last instance could be
> LastFrame. I used specific test methods on frame classes like:
> #isFrameComplete, #isLastFrame, #isSpare, #isStrike, #isOpen.
> 2) Beware that Bowling game should know only necessary things and delegate
> responsibility to its frames. Game itself knows that only if all frames are
> completed, game ends.
> 3) Total score is sum of all throws+bonuses of individual frames, etc.
>
> Does it help to start with exercise?
> David
>
>
>
>
>
> -----
> David Bajger
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Thanks,

Maybe I have to make it more clear.
What I trying to ask and what you have answered. Do I use the right
classes or too much classes there.
So if my idea of using these classes are right.

What you wrote is what I had in mind with 2  classes but the idea of a
lastFrame could also be working.
and I also agree with you about the responsibilities of the classes.

Roelof

Reply via email to