header - detail 構造

よくあるデータ構造として、header - detail 構造が挙げられる。

概念

主体の基本情報 header と、主体に従属する詳細情報 detail の組み合わせで、 主体側:1 に対して 従属側:N の関係になる構造である。

実際には、これらを複合的に組み合わせた構造で捉える必要のあることも多いだろうが、 主体側をグループや人物として捉えても成立するし、それらに汎用的なパラメータとして詳細情報を紐づけるなど、 この単位で現実なり業務の要素をオブジェクトとして捉えるスキルがあれば、それだけで幅広く現実をデータ構造に落とし込めるようになる。 それほどまでにこの構造は世に溢れている。

具象

開発言語で捉える場合、主体側が集合要素を捉えられる何らかのコンテナ構造（Array, List, Queue, Stack, Set, Map など）を介して従属側を所有あるいは参照する形で扱うのが一般的と言えるだろう。 Java であれば、このコンテナ構造のことをコレクションと呼称しているようだ。

扱うデータ構造と必要な操作に合わせたコンテナを組み合わせることで、実装者はデータを捉えやすくなる上にパフォーマンスも上げられるため、できれば幅広く扱えたほうが良いが、 一般的な業務では List, Set, Map 辺りの汎用的な構造が最低限使えれば、それらの組み合わせ次第で（効率を気にしなければ）他は代用できるため、そこまで困ることはないが、 できる限り設計に対して明確なコンテナで捉えることが望ましい。汎用的な構造では、どういう目的でどのように管理しようとしているのか？など用途が曖昧になる場合もあるため、 説明や管理方法が簡潔になる最適なコンテナが存在するのであれば優先的に選択すべきである。

個々の値を意識しなければ扱えない構造だった場合、開発中はそこまでの問題はないだろうが、一旦その開発から離れて数ヶ月や数年経ってから保守や拡張などの作業をする際に、 意味を思い出すための時間が必要となるため、オブジェクト指向的な理想としては、実データの個々の値を意識して直接的に扱うのではなく、抽象化した概念で扱える状況の方が 中長期に渡っての保守性が安定する。構造化的に捉えるのであれば、対象データが構造を使って隔離できており、各項目に対する説明なりドキュメント整備ができていれば そこまで時間が取られることはないだろう。