The Essence of Software のコンセプト設計では、各コンセプト自身の規則と、アプリ内でそれらを接続する規則を分ける。コンセプトの独立性とは、接続先の型や操作を直接参照せずに自身の振る舞いを定義できること。実際のアプリで互いに無関係であることや、すべてのコンセプトが同じ規模と重要度を持つことを意味しない。
たとえば「投稿を削除すると投票も消える」というアプリを考える。投稿のコンセプトは投稿を作成して削除する規則を持つ。投票のコンセプトは対象への票を管理し、対象に対する票をまとめて消す操作を持つ。「投稿を削除すると、その投稿を対象とする票も消す」という接続規則を、両者の操作を結びつける同期として置く。これは切り分けを考えるための例であり、すべての投票機能がこの削除規則を持つという主張ではない。
投票は対象の識別子を保持しても、その対象の本文や作成方法まで知る必要はない。対象の型をパラメータにすれば、投稿にもコメントにも同じ投票の仕組みを使える。合成時に対象を投稿へ具体化することと、投票そのものの定義が投稿の規則へ依存することは区別できる。
この合成には非対称性がある。投稿を消すと票も消すとしても、票を取り消したら投稿も消すとは限らない。このアプリの投票機能を使うには投稿が必要でも、その必要性を投票自身の規則に埋め込む必要はない。コンセプトの仕様はそれぞれ独立しており、操作をどう連動させるかは合成側の選択になる。
切り分けるときは、「この規則は仕組みそのものの説明か、このアプリでの使い方の説明か」と問う。「一人が同じ対象に入れられる票は一票まで」は投票自身の規則として説明できる。「投稿の作者は自分の投稿に投票できない」は投稿の作者と投票者を照合する、合成側の条件として表せる。完成したアプリでは両者が一体に見えるため、独立した目的を果たす単位 を取り出してから接続を考える必要がある。
本書の予約と通知の例でも、まず予約の仕組みと通知の仕組みを独立に設計し、その後でどの予約操作が通知を生むかを考える。通知方法や失敗時の扱いを予約そのものへ抱え込まず、通知側の問題として検討できる。対象を変えても使える仕組み として定義することが、この切り分けを支える。
Daniel Jackson『優れたデザインにとってコンセプトが重要な理由』ノート48「コンセプトの特徴」、pp.239–240。
Daniel Jackson の Three Stages of Enlightenment、Stage Three: Independence。
https://essenceofsoftware.com/posts/three-stages/
#software-design #concept-design #modularity #synchronization