Java Application Architecture » Base Pattern

Cohesive Modules

kirk knoernschild — Wed, 23 Dec 2009 02:11:24 +0000

For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.

Statement

Module behavior should serve a singular purpose.

Description

There are two key elements that affect module cohesion. These follow:

The rate at which the software entities within a module change.
The likelihood that the software entities within a module are reused together.

Based on these statements, it’s easy to draw the following conclusion:

Classes which change at different rates belong in separate modules.
Classes that change at the same rate belong in the same module.
Classes not reused together belong in separate modules.
Classes reused together belong in the same module.

Unforunately, while logical, these general statements do not always apply.

Module Reuse

kirk knoernschild — Tue, 22 Dec 2009 02:55:11 +0000

For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.

Statement

Emphasize reuse at the module level.

Description

One of the oft cited benefits of object oriented development is reuse. A large part of its failure is because classes aren’t the best reuse mechanism.

Manage Relationships

kirk knoernschild — Tue, 22 Dec 2009 01:49:58 +0000

For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.

Statement

Design module relationships.

Description

A relationship between two modules exists when a class within one module imports at least a single class within another module. In other words:

If changing the contents of a module, M2, may impact the contents of another module, M1, we can say that M1 has a Physical Dependency on M2. [JOUP02]