[SC] Object-Oriented Bowling Kata
Philip Schwarz
have you tried doing the Bowling Kata ( http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
) in an Object Oriented way?
If so, can you show me your attempt(s)? a Gist would be nice (https://
gist.github.com/)
So far I have only tried it once, in Groovy, specifying as little type
information as possible. Here is the result:
Game.groovy
https://gist.github.com/1079052#file_game.groovy
FrameSequence.groovy
https://gist.github.com/1079052#file_frame_sequence.groovy
Frame.groovy
https://gist.github.com/1079052#file_frame.groovy
GameTest.groovy
https://gist.github.com/1079052#file_game_test.groovy
Philip
José Manuel Beas
You may be interested in https://github.com/12meses12katas/Abril-Bowling
Regards,
JMB
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
Ron Jeffries
> have you tried doing the Bowling Kata (
> http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
> ) in an Object Oriented way?
Often ... I generally build it up in a TDD style, and usually find
that it doesn't really want a lot of objects. One can push more into
it, of course.
> If so, can you show me your attempt(s)? a Gist would be nice (https://
> gist.github.com/)
There are a bunch of articles on my site. Searching for "bowling"
will find a raft of them, in various languages and styles. I hope
you find some of them useful.
> So far I have only tried it once, in Groovy, specifying as little type
> information as possible. Here is the result:
Thanks. Not that you asked, so ignore this if you like, but here are
some observations about the code:
It's an interesting implementation, and a nice-looking one. I
noticed particularly the recursive creation of the sequence of
frames. It's clever ... which I like ... and I wonder if perhaps it
is too clever.
With designs that include a list of frames, each containing the
rolls pertinent to that frame, we generally find, as we do in this
example, tricky, if-bearing code like in sumOfNextTwoRolls() and the
isComplete() method. Personally, I don't like code like that because
it is hard to write and hard to understand later, when I am old and
my powers have declined, should that ever happen. :)
An interesting alternative is a Frame-ish object that contains the
complete list of rolls, with an index pointing to the first roll of
the specific frame. Such an object can reference "future" rolls
without linking through "future" frames, so that the collection can
become array-like rather than list-like.
Overall, the objects look to me to be a good combination, with most
of the functionality where it belongs (according to me, whoever that
is).
Ron Jeffries
www.XProgramming.com
I know we always like to say it'll be easier to do it now than it
will be to do it later. Not likely. I plan to be smarter later than
I am now, so I think it'll be just as easy later, maybe even easier.
Why pay now when we can pay later?
Carlo Pescio
>
the bowling game with the unpopular :-) design-code-test approach, and
documented it here (babbling + UML + code):
http://www.carlopescio.com/2007/07/get-ball-rolling-part-3-of-4-pretty.html
a few reflections on the approach/results in the following post:
http://www.carlopescio.com/2007/08/get-ball-rolling-part-4-of-4-told-ya.html
a critics of the code in the XP episode in the previous post:
http://www.carlopescio.com/2007/07/get-ball-rolling-part-2-of-4-most.html
and an introduction to the whole stuff in the first post:
http://www.carlopescio.com/2007/07/get-ball-rolling-part-1-of-4-i-guess.html
I used C#, which significantly evolved during the past 4 years, so I'm
pretty sure I could write better/shorter code today in the same
language :-). Still, it seems to me that it's capturing some domain
knowledge quite explicitly (e.g. I have an enum with Incomplete,
Spare, Strike, Complete values which simplifies a lot of reasoning),
while keeping the LOC count on a par with RCM's code.
Carlo
Steve Tooke
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
--
/tooky
Keith Nicholas
Ron Jeffries
> the bowling game kata is more an exercise in developing a scoring algorithm.
> It doesn't lend itself to OO so much. The concept of Frame isn't used so
> much. In fact many of the implementations I've seen wouldn't really be
> useful in *actual* software for *actually* scoring bowling in a bowling
> alley.
> If you want a more OO implementation. It would be better to write a
> "Bowling Alley".
> This gets a bit more interesting. Because the way scoring is done is a bit
> different than the "kata". As it has the concept of delaying the score
> until strikes and spares resolve. ( I think this is just because
> historically when pen/paper scoring you'd wait till you know the results of
> spares and strikes before writing it down.
All very true. The big advantage to the simple one that Chet and I
do is that you can do it in an hour or 90 minutes with full
discussion, commentary, and questions. As you move forward adding
more objects, with the delays and such that you mention, it becomes
much more interesting.
That said, a really good TDD / refactoring pair can build it up
almost entirely incrementally, with, of course, plenty of pauses to
talk about design. I think that's a good skill to have.
Good points, well made. Thanks!
Ron Jeffries
www.XProgramming.com
War remains the decisive human failure.
-- John Kenneth Galbraith
Curtis Cooley
<keith.n...@gmail.com> wrote:
> the bowling game kata is more an exercise in developing a scoring algorithm.
> It doesn't lend itself to OO so much. The concept of Frame isn't used so
> much. In fact many of the implementations I've seen wouldn't really be
> useful in *actual* software for *actually* scoring bowling in a bowling
> alley.
> If you want a more OO implementation. It would be better to write a
> "Bowling Alley".
> This gets a bit more interesting. Because the way scoring is done is a bit
> different than the "kata". As it has the concept of delaying the score
> until strikes and spares resolve. ( I think this is just because
> historically when pen/paper scoring you'd wait till you know the results of
> spares and strikes before writing it down.
> It has the concept of a UI showing frame scores.
> it has the concept of multiple people playing
> It has a concept of lanes
> etc.
> Regards,
> Keith
>
>
too big for a Kata. Maybe at an XP meeting it could be a one night
project which would let to practice planning and iterations and teams
working on different but related stories.
I do like the Bowling Kata though, but I might reveal some spoilers in
describing why, so:
<spoiler, maybe>
This is coming from someone who has only done this Kata three times,
so take it as you will:
I like the Bowling Kata as an OO Kata because it brings up at least
one smell or violation that you need to learn to recognize. Since you
can not accurately score a bowling game without knowing which frame
you are in, actually, you just need to know when you are in the tenth,
you have to count frames. That leads to a Frame most of the time,
especially your first time. Ironically, a Frame does not have all the
information it needs to score itself. In my first try and perhaps
others', that lead to a Scoresheet that scored the game by asking a
Frame questions. This implementation violates Tell Don't Ask, so you
have to decide if that is OK, or if you are going to try to find a way
to Tell a Frame to score itself and provide it all the information it
needs.
The recognition of the design smell that almost always creeps into
every first attempt is a very important skill, IMHO. I'd like to see
more of these "trap katas" that by design (wink wink) lead you down
the garden path for a bit.
</spoiler, maybe>
--
Curtis Cooley
curtis...@gmail.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
Philip Schwarz
You said:
>In my first try and perhaps
>others', that lead to a Scoresheet that scored the game by asking a
>Frame questions. This implementation violates Tell Don't Ask, so you
>have to decide if that is OK, or if you are going to try to find a way
>to Tell a Frame to score itself and provide it all the information it
>needs.
already learned (the hard way) that I needed to count frames, so, as
you said above, that led to a Frame object. But since by then I was
also aware that a frame does not have all the information it needs to
compute its score, the moment I decided to have a Frame object, I also
decided that a frame instance was going to know (have as a
collaborator) the next frame instance in the game.
Hearing you describing the Scoresheet approach, and how it violates
Tell Don't Ask, reminds me of the fact that in my attempt, when there
are three consecutive frame instances that are strikes, the first
instance violates the Law of Demeter because to compute its score it
reaches into the second frame to get the third frame, and then reaches
into the latter to get its first (and only) roll:
score = nextFrame.roll(1) + nextFrame.nextFrame.roll(1)
On the one hand, this is a clear violation of LoD since the 3rd
instance is clearly not an immediate collaborator of the 1st instance,
but on the other hand, the fact that the two instances are of the same
type, means that there is no breach of encapsulation. Is this a
degenerate case of LoD? An exception to the rule(/law/suggestion/
heuristic)?
Uncle Bob calls an LoD violation, e.g. a.getB().getC(), a transitive
navigation: just because A collaborates with B and B collaborates with
C, we don’t want classes that use A to know about C. But in my OO
version of the Bowling Kata, rather than transitive navigation, we
have two cases of reflexive navigation (at the class level at least):
the fact that F collaborates with itself, does not disclose to F any
information about any other class: F already knows all there is to
know about itself.
That is why I think I am not too worried about this violation.
Any thoughts anyone?
Philip
Philip Schwarz
>more of these "trap katas" that by design (wink wink) lead you down
>the garden path for a bit.
Ron Jeffries
wrote:
> When I tried my first (and only so far) OO version of the kata, I had
> already learned (the hard way) that I needed to count frames, so, as
> you said above, that led to a Frame object. But since by then I was
> also aware that a frame does not have all the information it needs to
> compute its score, the moment I decided to have a Frame object, I also
> decided that a frame instance was going to know (have as a
> collaborator) the next frame instance in the game.
> Hearing you describing the Scoresheet approach, and how it violates
> Tell Don't Ask, reminds me of the fact that in my attempt, when there
> are three consecutive frame instances that are strikes, the first
> instance violates the Law of Demeter because to compute its score it
> reaches into the second frame to get the third frame, and then reaches
> into the latter to get its first (and only) roll:
> score = nextFrame.roll(1) + nextFrame.nextFrame.roll(1)
> On the one hand, this is a clear violation of LoD since the 3rd
> instance is clearly not an immediate collaborator of the 1st instance,
> but on the other hand, the fact that the two instances are of the same
> type, means that there is no breach of encapsulation. Is this a
> degenerate case of LoD? An exception to the rule(/law/suggestion/
> heuristic)?
> Uncle Bob calls an LoD violation, e.g. a.getB().getC(), a transitive
> navigation: just because A collaborates with B and B collaborates with
> C, we don�t want classes that use A to know about C. But in my OO
> version of the Bowling Kata, rather than transitive navigation, we
> have two cases of reflexive navigation (at the class level at least):
> the fact that F collaborates with itself, does not disclose to F any
> information about any other class: F already knows all there is to
> know about itself.
> That is why I think I am not too worried about this violation.
> Any thoughts anyone?
It is certainly possible to eliminate this apparent LoD violation by
sending a different message to the following frame, something like
sumOfTwoRolls, which it can implement by something like
if selfIsNotStrike return roll1 + roll2
else return roll1 + next.firstRoll.
Now no one talks to anyone he doesn't know, nor uses protocol he
should not know.
I've never found a solution with a list of Frames that I really
liked, however, mostly because the overall concern is something like
sumOfFrames, and that question is more of an array thing than a list
thing. In addition, even in examples like the one above, one is
talking to the frame in elementary terms like firstRoll rather than
more abstract such as frameScore. So the abstraction limps anyway.
Of the solutions I've come up with, the one I favor the most is one
that lets the Frames know internally about rolls, and externally
expose only the Frame score during execution. (During construction
might be a different matter.) To do that, I think of the Frame as an
overlapping "parsing" of the roll array, with each Frame able to see
all the rolls, and each Frame object knowing which roll is its first
roll. So Frame knows rollArray and startIndex and can ask and
answer all its questions internally, mapping roll1 into
rolls[startIndex] and so on.
Anyway, to me, this model encapsulates Frame perfectly from the
outside and has a simple implementation on the inside. My LUA
implementation does this fairly nicely if you are willing to trek
through the LUA:
http://xprogramming.com/articles/lua-bowling-now-a-frame/
It may be that I need to do a version with this structure from
scratch.
Which brings me to a question about design, whatever that is, and
TDD. Going back over the bowling articles on my web site (no, don't
do that, it's a trap), and reflecting over the many times Chet and I
have done bowling as a demonstration, this becomes clear:
If we have a design in mind, we can TDD from scratch, stay focused
on a top-level view of tests, and produce that design nicely.
That is, we can build a procedural bowling, a bowling with a list of
Frames, a bowling with an array of Frames, a bowling with no frame
object at all ... all just using tests consisting of lists of rolls
and their associated frame score.
We always learn something about that design that makes it better,
and we often learn enough so as to change our original design plans.
I consider both of those to be good things.
Ron Jeffries
www.XProgramming.com
I try to Zen through it and keep my voice very mellow and low.
Inside I am screaming and have a machine gun.
Yin and Yang I figure.
-- Tom Jeffries
Andreas Leidig
I did one in java (Eclipse workspace): https://github.com/leider/leidersstuff/tree/master/BowlingCounter
Looking forward to comments,
Andreas
Steve Tooke
Of the solutions I've come up with, the one I favor the most is one
that lets the Frames know internally about rolls, and externally
expose only the Frame score during execution. (During construction
might be a different matter.) To do that, I think of the Frame as an
overlapping "parsing" of the roll array, with each Frame able to see
all the rolls, and each Frame object knowing which roll is its first
roll. So Frame knows rollArray and startIndex and can ask and
answer all its questions internally, mapping roll1 into
rolls[startIndex] and so on.
/tooky
Matteo Vaccari
> Hello, Philip. On Sunday, July 17, 2011, at 4:19:20 AM, you wrote:
>
>> have you tried doing the Bowling Kata (
>> http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
>> ) in an Object Oriented way?
>
> Often ... I generally build it up in a TDD style, and usually find
> that it doesn't really want a lot of objects. One can push more into
> it, of course.
Hi Ron,
have you considered "testing" a bowling score design by trying
variations in the scoring rules? Suppose we must support a 12-frames
game? Up to three balls per frame? A variable number of pins, such
as 1 pin in the first frame, 2 in the second... ?
If I try to add these variations to the usual "one object" bowling
score solution, I find that it produces an unmaintainable mess of IFs.
Sometimes I use this to explain why we need objects :-)
I have a few slides on this subject
http://www.slideshare.net/xpmatteo/20101125-ocpxpday
Matteo
Ron Jeffries
> have you considered "testing" a bowling score design by trying
> variations in the scoring rules? Suppose we must support a 12-frames
> game? Up to three balls per frame? A variable number of pins, such
> as 1 pin in the first frame, 2 in the second... ?
No, I've not tried that. It's not really to my purpose, nor do I
find the notion particularly realistic. Which doesn't mean it
mightn't be fun!
> If I try to add these variations to the usual "one object" bowling
> score solution, I find that it produces an unmaintainable mess of IFs.
> Sometimes I use this to explain why we need objects :-)
One would always put objects in when the problem and solution begin
to call for them. If I were trying this sort of thing, I would
expect the code to tell me that it was time to add more objects.
With the simple version Chet and I do, which is scaled to about an
hour or ninety minutes, we almost have to force objects into the
design. The problem is too simple to need them.
> I have a few slides on this subject
> http://www.slideshare.net/xpmatteo/20101125-ocpxpday
Very interesting! Seems like it would be fun to try!
Ron Jeffries
www.XProgramming.com
Those who attain to any excellence commonly spend life in some single
pursuit, for excellence is not often gained upon easier terms.
-- Samuel Johnson
Philip Schwarz
>will find a raft of them, in various languages and styles. I hope
>you find some of them useful.
>Not that you asked, so ignore this if you like, but here are
>some observations about the code:
>It's an interesting implementation, and a nice-looking one.
>I noticed particularly the recursive creation of the sequence of
>frames. It's clever ... which I like ... and I wonder if perhaps it
>is too clever.
saying that the recursion is too clever. I guess you are saying that
the idea of a frame collaborating with the next frame is too clever,
due to the issues you describe below.
>With designs that include a list of frames, each containing the
>rolls pertinent to that frame, we generally find, as we do in this
>example, tricky, if-bearing code like in sumOfNextTwoRolls() and the
>isComplete() method. Personally, I don't like code like that because
>it is hard to write and hard to understand later, when I am old and
>my powers have declined, should that ever happen. :)
>An interesting alternative is a Frame-ish object that contains the
>complete list of rolls, with an index pointing to the first roll of
>the specific frame. Such an object can reference "future" rolls
>without linking through "future" frames, so that the collection can
>become array-like rather than list-like.
avoid the idea of an index.
The Game class and GameTest class are unchanged. Here are the new
Frame and FrameSequence https://gist.github.com/1116154
Overall, the code is simpler. Frames are much simpler now:
* they no longer have the next frame as a collaborator. Instead, they
are told what their bonus rolls are.
* their tricky, if-bearing code is gone: it has moved into the frame
sequence, where it got simplified
The logic for obtaining the bonus rolls is simpler because the rolls
are just read off a roll list, rather than by navigating the frame
sequence.
Do you prefer the following version of the frame, where the
distinction between rolls and bonus rolls is maintained purely to more
closely model the domain?: https://gist.github.com/1116157
Philip