Design Recipe Deliverables

Here are the items you need to include for each question:

For Each Data Definition:
1. A set of struct definitions, if necessary.
2. A constructor template that specifies how to build values for this data definition.
3. An interpretation, explaining the meaning of each element in the data in terms of the information it represents. The meaning should be the meaning of the data, not of how it used in the program.
4. A destructor template for examining values of this kind of data.
5. Examples if they will be helpful in understanding the interpretation, or for use in tests. If the examples are primarily for use in tests, you may put them near the tests.
For Each Function:
1. Contract: a specification of data definitions for the arguments and the result. If you write
```
    list-numbered : ListOf<Number> Number -> ListOf<Number>
```
  then your function must take any list of numbers and any number and produce the output that is described by the purpose statement, unless the contract is qualified by an invariant (WHERE-clause). We will talk about WHERE-clauses in module 7.

Additional Deliverables and Coding Conventions for Object-Oriented Programs

For Each Interface:
1. Interface names should end in <%> .
2. A purpose statement for the interface
3. For each method in the interface, a contract and purpose statement of the method. Contracts should always be written in terms of interfaces, not classes. You may write Widget in place of Widget<%> in contracts if you prefer.
For Each Class:
1. Class names should end in % .
2. A purpose statement saying what information the class represents.
3. A constructor template showing how to build an object of that class.
4. Every field (both init-fields and other fields) must have an interpretation stating what kind of data is contained in the field and what that field represents. If there is an invariant relating two or more fields, it must be stated.
5. A set of unit tests that exercise every method and function in the class. In our test framework, these will be located outside the class.
6. Every method in the class must come from some interface that the class implements. Exception: methods named for-test:... need not be part of any interface, but they may only be used for testing.
7. A class may not contain any private methods. Private methods should be written as ordinary functions instead.
For Each Method:
1. A contract that is identical to the contract in the interface.
2. A purpose statement that specializes the purpose statement in the interface to the current class.
3. Examples, if these are necessary to clarify the purpose statement. These should generally be stated in human-readable language.
4. A Design Strategy, if needed to explain the method definition. These can be any tweet-sized description of how your code works.
5. Tests. These will be part of the unit tests for the class.

Last modified: Tue Nov 3 16:24:59 Eastern Standard Time 2015