Notes on Glenford Myers books

Reliable Software Through Composite Design

A module is analagous to a function or procedure in most programming languages. Two properties of modules:

Module strength

A measure of the "goodness" of a module

Module coupling

A measure of the interconnections and relationships among modules

Module Strength

Scale of module strength from worst to best:

Coincidental

No meaningful relationships amongst the elements. Think traditional DRY coding where you remove a repeated set of statements from several functions. This is bad because the meaning of the duplicated statements is likely context dependent, and once the context changes in of those locations the code must either be reduplicated or the function broken by adding a test to determination whether the old or new case is meant.

Logical

Module that performs a set of related operations based on a flag (ex. create, update, delete). Inherited class methods often have this kind of strength.

Classical

Same as logical strength, except that the elements are related in time. For example an init module. These tend to have the weaknesses of Logical strength but are often simpler.

Procedural

Perform more than one function, but the functions are related in respect to the procedure of the problem. Similar to logical strength but instead of being lumped together due to temporal relation they are lumped together because they perform one multi-step logical procedure where the steps are not related and tend to get broken apart or become multi-way choice methods based on a flag.

Communicational

Same as procedural but all of the elements communicate by referencing the same data on passing messages amongst themselves (ex. the output of one element is the input of another).

Informational

Performs multiple functions dealing with a single data structure (think classes and traditional information hiding module design). Ranked lower than functional since multiple operations on a single data structure tend to produce intertwining and complexity.

Functional

All of the elements perform a single function transforming an input into an output (ex. sin, cos, etc.).

Module Coupling

Scale of module coupling from lowest to highest:

Content

Largely confined to assembly language programs these are two modules that tightly share code or data in a way that routes around the defined interfaces. A modern example might be defining a function within a function where the inner function operates on data in the outer function.

Common

When two modules reference a shared global data structure (e.g. in the form of some kind of shared environment). This means the modules are tightly coupled through that data structure and changes to the data structure may entail changes to all the modules that access it.

External

When two modules reference the same symbol (ex. a global variable or a global constant).

Control

One module passes an element of control (a flag or switch) to another module that the caller intends to directly affects the way it executes. This includes functional-style programming when passing a lambda or function pointer to a method. The calling module may now have to include logic to determine the value to pass, and the called module needs to define its interface in a way that now takes into account all possible uses.

Stamp

Two modules reference the same non-global data structure - classes in object-oriented languages or operations on a struct instance in procedural languages. This causes data structure changes to affect all methods that modify it, makes the functions less generic (especially if they only need a subset of the data), and makes reuse in different contexts more difficult.

Data

Two modules interact by passing all data as arguments. Communication is done only through the pertinent data items instead of via an entire data structure. Modules that are data coupled are thus highly independent.

Last update on 7E5105, edited 1 times. 1/1thh