Presenters: James Packard, An Vu
Head Reader: Andrew Zhang
Assistant Reader: Nathan Castro-Pacheco
Secretary: Brian Rego
Presenters: Jiacheng Pang, Anthony Mu
Head Reader: Samuel Richards
Assistant Reader: Tianqi Li
Secretary: Anmol Sakarda
Presenters: Zain Aaban, Thomas Sarni
Head Reader: Ken Zou
Assistant Reader: Michael Fitzgibbons
Secretary: Rachel Kalafos
The design recipe has two dimensions: the process and the (complexity of the) data definition.
Both generalize from the small programs of Fundamentals I and II, and both are helpful in settings that deal with large components.
Each component should serve one purpose or compose other components (and do nothing else). If you can’t articulate a clear and simple purpose statement for a component, this is likely a hint that it is overloaded.
Especially in OO PLs, a component’s purpose is to represent some information
with data and to combine it with functionality. Often, this is a single
class. On other occasions, it is a bunch of classes and their
relationships. (See Modules and Packages in Java.) If a component consists of
sub-components, say classes, it should serve a clear and simple
purpose. Articulate a purpose statement if it isn’t obvious. —
Embed examples of data representations and explain them in components. That way you can re-use them in other components too, especially if you must compose examples.
Components that integrate others need integration tests. Unit tests discover bugs in units. Integration tests discover bugs related to the interaction of distinct units.
Debugging. Write tests first. Trace them down.