Information Hiding & Boundaries
Positioning
本サイトで扱う Failure Pattern の多くは、 コードの複雑さそのものではなく、 変更理由や判断前提が露出すること によって引き起こされている。
Information Hiding や Boundary は、 実装詳細を隠すための技巧ではない。 変更・判断・責務の影響範囲を限定するための 構造的な分離原理として扱われる。
Scope
本 Appendix では、 モジュール設計や API 設計の具体論は扱わない。
Interface 定義や分割手法は、 判断前提を隔離するための 一つの表現手段として参照されるにとどまる。
技術スタックや設計パターンの選択は、 本サイトでは扱わない。
Mapping
以下は、本サイトの構成要素と、 Information Hiding / Boundary に関する考え方との対応関係を整理したものである。
| 本文の要素 | Information Hiding / Boundary の系譜における位置づけ |
|---|---|
| Context-Blind Change | 判断前提が境界を越えて漏れ出す状態 |
| Boundary-Blind Integration | 境界を意識せずに変更・統合が行われる状態 |
| Countermeasures | 判断前提・変更理由を境界内に閉じ込める介入 |
| Resulting Context | 境界を越えずに判断・変更が行える状態 |
Rationale
Parnas が指摘した Information Hiding の核心は、 実装を隠すことではなく、 何が変わりうるかを隔離することにあった。
Failure Pattern における境界の破綻は、 技術的結合の問題というよりも、 判断前提や変更理由が 制御不能な形で伝播することによって生じる。
Context-Blind Change や Boundary-Blind Integration は、 境界が「存在しない」状態ではなく、 境界が判断単位として機能していない 状態を示している。
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.