On this page:
How to Design Programs
8.3.0.5

Lecture 13: Practice Design Inspections

09:15am

Design Inspection:

Presenters: James Packard, An Vu

 

Head Reader: Andrew Zhang

Assistant Reader: Nathan Castro-Pacheco

Secretary: Brian Rego

01:35pm

Design Inspection:

Presenters: Jiacheng Pang, Anthony Mu

 

Head Reader: Samuel Richards

Assistant Reader: Tianqi Li

Secretary: Anmol Sakarda

04:35pm

Design Inspection:

Presenters: Zain Aaban, Thomas Sarni

 

Head Reader: Ken Zou

Assistant Reader: Michael Fitzgibbons

Secretary: Rachel Kalafos

How to Design Programs

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.

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. — In functional PLs, think about modules as components (plus submodules).

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.

Presentations.

Paneling.