Object aficionados worldwide are concerned that the procedural bowling solution presented last time is just not robust enough. They want to see how we would make it score the frames incrementally. Frankly I haven’t the slightest idea.

Here’s the Bowling Game again. This time I’ll take a simpler approach, along the lines I usually follow when I do a Test-Driven Development demonstration. The result is strikingly simpler than the preceding “object-oriented” solution. What does this tell us about TDD and how to use it?

When I demonstrate Test-Driven Development using the Bowling Game example, I begin by describing the problem and inviting the attendees to do a little up front design about what objcts we may need. Then I take a very simple approach that produces a rather simple single-class solution, with none of the complexity we anticipated. I’ve been wondering how to drive the development to cause the creation of some of the classes that are anticipated, supposing that we might have some actual need for them. Here’s an example of doing TDD with a bit bigger “design” in mind.