Instead of a Friday Java Quiz, I'll pose a challenge. And it is not a challenge to your Java skills, but a challenge to the Test-First Design doctrine, which holds that a test-first approach can result in a better or simpler design.
I first witnessed this principle at work at the first No Fluff Just Stuff conference in St. Louis several years ago, where I sat in on Uncle Bob's session on test-first design and followed his "score a bowling game" demonstration.
I have been following a test-driven approach ever since, and I have benefited enormously from this approach: this is true especially in the responsibility allocation among cooperating classes, untangling tightly coupling, and API designs.
However, I have always felt that certain systems can only be designed with enough knowledge about the domain that might not be gained through the mere writing of tests. This is particularly true in areas where non-trivial theories are involved in the solution of a problem. My usual example is "You can't write Math.sin() with a test-first approach."
It seems to me that the test-first design is applicable for trivial problems, but not for complicated problems where the naive solution is the wrong solution.
With that in mind, here's today's Java challenge: Using a test-first approach, and without resorting to any text books, or Google, or looking at the sources of existing regular expression implementations, write a simple regular expression matcher that supports the following features:
c: literal character c
. (period): any single character
^: beginning of input string
$: end of input string
*: zero or more occurrences of the previous character
Previous Topic
