Next: Isolating the Symbol Up: Design

Modularity Principle

Unrelated parts of the system should be separated, and related parts of the system should be grouped together. Access to a grouped component should be through a simple interface; normally a small group of functions, each with a few parameters. We say that the details of a component are hidden by the interface. Why do we design this way?

• Separating unrelated components decreases the chance that modifying one component will adversely impact the other. It will also make it easier to reason about the individual components because there is less to look at when separated. Furthermore, it is easier to reuse separated components because it is possible to access the functionality of one without unnecessarliy accessing the functionality of the other. If the implementation of each component is appropriately hidden by its interface, then changing the implementation or extending its function should not change the existing interface. Changing an existing interface is problematic because all clients of the interface must be changed as well.

• Putting related parts together makes it easier to see the relationships between them when debugging them or adding functionality to them. Successfully isolating a group of parts in a module (or class) depends on choosing a group of elements that can be elegantly presented to other modules with a concise, easy-to-understand interface. Just because there is an interface does not mean that a component is easy to use; a poor interface reveals unnecessary information about a component, making it harder to use and less resilient to change.

This principle can be applied to deciding what code goes in a function, when to define a class, or what files to put classes and functions.

The basic process can be defined as identifying the design decisions in the code that may change in the future. A design decision is a choice in how to implement something, such as a choice to implement a list with a linked-list or to represent scoping with a stack. For each design decision that is deemed likely to change and to be costly to change, a module can be created to hide that design decision. Consequently, clients of the code access the module interface rather than the design decision directly. When the design decision changes (and the interface stays the same), the client is effectively protected from the change.

Examples:

• Isolating the Symbol Table Representation.
• Separating Parser from Actions.
• Breaking Down Composite Functions.