Information Hiding & Boundaries
Positioning
Many of the Failure Patterns addressed in this site are caused not by code complexity itself, but by the exposure of reasons for change and decision assumptions.
Information Hiding and Boundaries are not techniques for hiding implementation details. They are treated as structural separation principles for limiting the scope of impact of changes, decisions, and responsibilities.
Scope
This Appendix does not address specifics of module design or API design.
Interface definitions and partitioning methodologies are only referenced as one means of expression for isolating decision assumptions.
Choices of technology stacks or design patterns are not addressed in this site.
Mapping
The following organizes the correspondence between elements in this site and concepts related to Information Hiding / Boundary.
| Element in Main Text | Position in Information Hiding / Boundary Lineage |
|---|---|
| Context-Blind Change | State where decision assumptions leak across boundaries |
| Boundary-Blind Integration | State where changes/integration occur without awareness of boundaries |
| Countermeasures | Intervention to confine decision assumptions and reasons for change within boundaries |
| Resulting Context | State where decisions and changes can be made without crossing boundaries |
Rationale
The core of Information Hiding as pointed out by Parnas was not hiding implementation, but isolating what is subject to change.
Boundary failures in Failure Patterns arise not so much from technical coupling problems, but from decision assumptions and reasons for change propagating in uncontrolled ways.
Context-Blind Change and Boundary-Blind Integration indicate not a state where boundaries "do not exist," but a state where boundaries are not functioning as units of decision.
References
- David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
- David L. Parnas, Designing Software for Ease of Extension and Contraction, 1979.
- Barbara Liskov, Data Abstraction and Hierarchy, 1988.
- Fred Brooks, No Silver Bullet—Essence and Accidents of Software Engineering, 1987.