Design Recipe for an Object-Oriented Program

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.

Design each of the classes

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

Write testing code

Since you've already tested and debugged each method in each of the individual classes, all that remains is integration testing: making sure that all your classes work together as well as separately.

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.

Test and debug

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!