Lecture 13: Practice Design Inspections

09:15am

01:35pm

04:35pm

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.