Tensions in Practice: Familiar functional divisions and localized edits¶
A toy reader and checker
A file reader and a checker both know the same data format. Put them in separate modules and a format change requires coordinated edits in both. Put their format-dependent parts behind one stable result interface and the selected change can stay in that module. The latter boundary localizes this change but combines responsibilities and may be wrong for another pattern of change.
Keep functions separately organized
Let reading and checking have independent ownership and implementation.
Localize a likely change
Keep knowledge of the selected file format behind one boundary.
Why these aims pull against each other
A boundary that looks natural by function can cut through knowledge that must change together. Moving that boundary trades familiar separation for a larger shared change unit.
Choose an arrangement to see what changes and what remains difficult.
Arrows show the stated work, authority, or access paths. Position, length, and color do not measure time, risk, cost, or performance.
What this choice protects
What it costs
When it fits
Compare the arrangements
Split by function
Keep the format-aware reader in module A and the format-aware checker in module B.
- What it protects
- Reading and checking have distinct module ownership and can evolve independently for other changes.
- What it costs
- The selected format change requires edits in both modules and coordination across their boundary.
- When it fits
- Fits when independent changes to the functions matter more than the frequency or cost of joint format changes.
Illustration note: This is an invented bounded arrangement. Arrows state the selected rights, flows or dependencies; they do not predict behavior or quantify outcomes.
Group format knowledge
Place the format-aware reader and checker inside one module, which exports the same stable result contract to its caller.
- What it protects
- This selected format change can be handled within one module boundary.
- What it costs
- The combined module has more responsibility and requires a stable abstraction; other changes may still cross the boundary.
- When it fits
- Fits when format knowledge changes together and the caller’s promised result can genuinely stay unchanged.
Illustration note: This is an invented bounded arrangement. Arrows state the selected rights, flows or dependencies; they do not predict behavior or quantify outcomes.
What this illustration does—and does not—establish
The canonical tension supplies the mechanism. The named setting, arrangements, conditions and costs are editorial constructions, not observed outcomes or universal prescriptions.
- The caller contract is held unchanged in both arrangements. If the format change alters the promised result, this isolation claim no longer applies.
- Disconnected nodes mean no edit obligation in this selected change, not absence of runtime communication or testing.
- Grouping is not a universal recommendation; it must follow actual change patterns, and interfaces have cognitive and implementation costs.
Source entries
Modularity
Modularity: Boundary determination and misplaced coupling supplies this local tension. The concrete setting and selected alternatives are explicitly editorial applications.
Boundary determination and misplaced coupling
The tension is between the theoretical principle (modules should hide change sources) and practical reality (some changes affect multiple modules, forcing either boundaries to be violated or expensive redesign).
Boundaries should localize likely changes
Parnas's foundational principle (1972) is that modules should be chosen to hide the likely sources of change: if a change is likely to affect the representation of data, that data should be localized to one module; if two modules are likely to change independently, they should be separate.