Design Recipe Deliverables
For each question of a problem set, your solution needs to include the following items.
For each data definition:
A set of
structdefinitions, if necessary.
- A constructor template that specifies how to build values for this data definition.
- An interpretation that explains the meaning of each element of the data in terms of the information it represents. That meaning should be the meaning of the data, not some description of how the data are used in the program.
- An observer template for examining values of this kind of data.
- Examples, if they help readers to understand the interpretation, or for use in tests. If the examples are primarily for use in tests, you may place them near the tests.
- A set of
For each function:
a specification of data types for the arguments
and for the result.
If you write
list-numbered : ListOfNumber Number -> ListOfNumberthen your function must take any list of numbers and any number and produce the output specified by the purpose statement, unless the contract is qualified by a precondition or invariant (WHERE clause). We will talk about WHERE clauses in Module 07.
short noun phrases describing the arguments and what the
function is supposed to return.
Typically phrased in terms of information, not data.
Purpose statements are usually stated in GIVEN/WHERE/RETURNS
style, where each of those keywords is followed by a short
GIVEN: a temperature in Fahrenheit RETURNS: the corresponding temperature in Celsius GIVEN: a Cat c and a Scene s RETURNS: A scene like s, except the cat c has been painted on it. GIVEN: a list of numbers lon and a number n WHERE: n = (length lon) RETURNS: a list of numbers like lon, except each number is multiplied by its distance from the end of the list.You may omit the GIVEN part by referring to the given arguments in the RETURNS part. Sometimes this is easier than writing the GIVENS part separately, but sometimes it is harder. Examples:
RETURNS: the temperature in Celsius that corresponds to the given Fahrenheit temperature. RETURNS: A scene like the given one, except that the given cat has been painted on it.
- Examples: the examples should illustrate the different behaviors of the function, and should be designed to help readers to understand the purpose statement more quickly.
a short description of the idea used to derive the
function definition from its purpose statement.
Common design strategies include:
- combine simpler functions
- use template for [data type] on [variable]
- divide into cases on [condition]
- use HOF [function] on [variable]
- call a more general function
- Function Definition: your definition of the function should make sense to the computer and also to human readers. If your design strategy is "use template", for example, then your function definition should follow the template for the appropriate data type(s).
you will generally define a separate test suite for
each function by writing something like
(begin-for-test (check-equal? (length lobs-1) (length (bombs-after-tick lobs-1)) "bombs-after-tick did not return a list the same length as its input") ...)Tests created using
begin-for-testwill be executed as though they appeared at the end of the file. In other words,
begin-for-testis a magical syntax that allows you to place your unit tests near the function definition(s) they're testing, even if some of the tests refer to functions or values that haven't been defined yet.
- Contract: a specification of data types for the arguments and for the result. If you write
More deliverables will be required when we get to object-oriented programming.