home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
design-recipe
the design recipe
The design recipe1
is a series of steps to guide you through writing a program.
Not only does it get you past any initial blank-screen anxiety,
but its structure helps guide your thinking in a way which reduces
the number of bugs you'll encounter.
This recipe will get further fleshed out as the semester progresses;
ignore (for now) the greyed-out text.
For each entire project/homework
-
Data analysis — What are the pieces of information
at hand, for this problem, and
which data types should be used to represent them in the program?
(E.g., int, String,
boolean, ...?)
-
Examples of the data.
If you are writing a new class,
make a bunch of example instances.
(Once we've introduced constructors, this entails writing
the constructor for the class, so that you can call it.)
(If using BlueJ with unit test tools enabled,
you can create these these instances by right-clicking on the class;
then you can right-click on the test-class
and select “Bench to test fixture”.)
For each individual function/method in the homework…
-
Signature — for each method (function),
specify its name, what input parameters it needs (name and type),
and what type of information it will return.
(See our mantra
for signatures)
-
Complete the stub function, and compile.
Note that you still haven't yet written any code which
computes a solution.
- Comments (written in
javadoc).
Describe what each parameter means
(for example “the price of the item, in dollars”,
or “the number of students officially enrolled in the course”)
as well as the meaning of the return value.
(You can do this either before or after your test cases.)
-
Test cases:
Write 2-3 test cases (or more, as appropriate).
- A test case includes input(s), and the
expected output.
- Include at least one test with a degenerate input
(if appropriate). For numbers, consider 0, 1.
For Strings, consider the empty string.
- Include at least one typical-use case.
- Consider whether fractional or negative numbers are
possible inputs. Either include a test case with them,
or make sure your comments state clearly they are not allowed.
-
The body of the function.
This is the only non-automatic part of the process.
Reflect on the test cases you worked through by hand:
how did you get from the input to the output?
What is the general case?
Things to help you on your way:
- Remind yourself of your parameters and fields — these
are the only pieces of info you have, to calculate your answer!
- What are the types of each of these data?
What pertinent methods can you call, on objects of that type?
-
Test — run the test cases you already wrote down
from step 2.
Does your program give the results you expect?
-
Refactor — review and (as necessary) rewrite your
code. Does it obey the The Laws of Programming?
1This design recipe
is adapted from How to Design Programs,
by Felleisen, Findler, Flatt, and Krishnamurthi.
↩
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
rad�ford.edu