Design Recipe for an Object-Oriented Program

This recipe is patched together from a variety of sources, including the Arnow & Weiss book, the Felleisen Findler Flatt & Krishnamurthi book, and the Xtreme Programming project.

Define the problem

State the problem clearly and unambiguously in English. If you can't do this, you have no hope of writing a program to solve it.

Sample Scenario(s)

Imagine a situation in which this problem would need to be solved. Describe where the information comes from, how some other entity (human or not) might ask for the problem to be solved, what kind of results are produced, and what is done with them. If you're working on a highly interactive program, this is a good time to write a "script" for one or more interactive sessions with the user: what does the user do, what does the program do in response, etc.

Find the Important Objects

A simple rule of thumb for this is to go through the problem description and the scenario and underline all the nouns. Then apply common sense to weed out the ones that aren't really important or that don't need to be modelled inside the computer program. If you see obvious relationships among different kinds of objects (e.g. this "is a kind of" that, this "contains one (or more) of" that, this "uses the services of" that, etc.), write those down too. A class diagram is a good concise way to display this relationship information.

Specify the public interface to each class

Don't write code, except perhaps for some method headers if you find that the clearest way to specify an interface.

Write testing code for the whole program

In the step after this, you'll design, implement, and test each individual class. At this step, concentrate on integration testing: testing how the classes work together, typically from a separate Testbed class. You may need to comment out many or all of your test cases, uncommenting them later as individual classes and methods are implemented, but it's important to start writing them down now.

To the extent that your "sample scenarios" can be automated, write a static void test() method that generates instances of various classes and invokes methods that involve interaction among them. If your "sample scenarios" are driven by user input, you may need to just start up the program and try each scenario by hand.

Design, implement, and test each of the classes

For each class, go through the design recipe for classes.

Test and debug the whole program

1. Compile your program. If it has syntax errors, read the error messages carefully, figure out what they mean, fix them, and compile again until there are no syntax errors.
2. Once there are no syntax errors, run your test method. If it produces run-time errors, read the error messages carefully, figure out what they mean, fix them, and compile again until there are no syntax or run-time errors.
3. For each of the examples in your test method, observe the actual output. If it's not what you expected, either you were expecting the wrong thing (possible, though unlikely) or there's a bug in your program. Figure out how the answer is wrong (not just that it's wrong) and how this wrong answer could have happened, fix it, and compile and run again. When you fix a bug, be sure to re-examine the previously working examples to make sure they still work!