I want to reply to some of your insights here, because
I think it is sometimes a matter of personal��preference on
a problem solution,��so I want��to compete with your��opinion
here. I might be totally wrong, when I see your way of
solution and tell just 'you were right, your solution is
more elegant'. For me it is an approach discussion.
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.
We are using OO language to isolate problems into
particular objects and their responsibility. I would say
there is no "ugly problem to care about". Sometimes it
can be the "right" factoring of a problem into classes
and sometimes it is too hard and that is the point. I
think this exercise is about finding the right place to
delegate problems in fitting classes that��are small
enough. Of course, it can be resolved by one "long
method" with a total of less lines of code. But in
general I like more verbosity over one compact algorithm
that wouldn't tell readers too much. This is a personal
preference.
��
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.
Way of evaluation is definitely��relevant. Key thing
for me was to realize "I always need to evaluate the
current state of things", the same way, when you play
bowling.��
- Each frame should be able to tell, if it is
completed��from the point of actual��throw. So, why not
just pass throws by game into the current frame, that
would tell, if it is completed or not?
- Frame can calculate score immediately, but
bonuses��can be later. Maybe it isn't 'the throw thing'
to care about. It is a matter of the game, that can tell
when is the right moment to evaluate bonuses. Game can
delegate such information to the passed��frames at the
right moment (maybe after each thow, or maybe when the
current frame is completed?). But maybe my previous
sentence can be interpreted as:�� "this is a big hammer
for this solution already".��
��
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.
Well, why not just initialize frame by "collection of
1-2 (maybe 3) throws"? Depending on the actual state of
collection, frame just tells the game "I have enough
throws, so you can pass throws to my neighbor". Rules
for completeness can be different, based on
circumstances. For me, it is a matter of frame
responsibility to deal with this.
��
- 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).
When bowling in real, you can determine the score of
the current frame. But bonuses are computed later, so
maybe the game should tell (after each throw), when to
evaluate bonus.�� "Hey, my passed frames, I'm passing you
this information, so evaluate your bonus now".��
��
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.
��
It depends on how "moderately complex algorithm" will
be readable for end users. Sometimes it is a real
struggle to determine "what a hell is going on here",
because the given method just does too many things in
one class. For me, separating throws into frames makes
the whole thing more understandable to readers,��because
they can imagine something from real life (real game).
Again, this is personal preference. I've seen few times
that "moderately complex algorithms" were extended by
other developers into "severe too-complex algorithms".
Problem is that developers don't do refactoring at the
right time (most probably because of lack of time and
time pressure on projects). On the other hand, I
understand it isn't a problem of this artificial
exercise and agree that focus should be just on��existing
problem statement and not hypothetical problem.����
I did this exercise some time ago and when I look at
it now, honestly I'm not satisfied with my solution,
especially the way bonuses are stored and evaluated in
normal vs last frame. But here is the thing: it is
isolated on one given place and used on one other place,
I can rewrite it maybe more easily.
��
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