お互いに知り合いでないこと

次は、あるシステムの設計書の一部を要約したものである。

データベースに登録されている商品の名前を表形式で表示する「一覧画面」と、その中から選ばれた１つの商品について、詳細な情報を表示する「詳細画面」がある。

一覧画面
・画面を開くときの処理
　データベースから全ての商品の ID と名称を取得し、表形式で表示する。
・一覧の行がダブルクリックされたときの処理
　「詳細画面」を開く。

詳細画面
・画面を開くときの処理
　「一覧画面」から、ダブルクリックされた行の ID を取得する。
　その ID をキーにして、データベースからその商品の詳細情報を検索し、表示する。

ここで、詳細画面と一覧画面の関係に注目してほしい。何か変な感じがしないだろうか？

一覧画面は、詳細画面を開いている。言い換えると、一覧画面は詳細画面のことを「知っている」。一方、詳細画面も、一覧画面から ID を取得しているのだから、一覧画面のことを「知っている」ということになる。つまり、一覧画面と詳細画面は、お互いに「知り合い」だということになる。

日常的な感覚では、こうした関係は何もおかしくない。しかし、システム設計という視点から見ると、このような関係は好ましくないのだ。

★
結論から言えば、このような「知っている」という関係は、できる限り一方通行にすべきである。

上記のような、いわゆる親画面（開く側）と子画面（開かれる側）の関係では、「親画面は子画面のことを知っているが、子画面は親画面のことを知らない」という関係にするのが一般的だ。

詳細画面に必要な機能は、「ID に該当する商品の詳細情報を表示する」ということである。「一覧画面から開かれる」という前提は全く必要ない。

例えば、将来、「在庫管理画面」だとか、「見積書作成画面」といった他の画面を作ることになったとしよう。そうした場合、それらの画面からも、「詳細画面」を開きたくなるのではないだろうか？　しかし、上記のような設計では、詳細画面は一覧画面以外の画面からは開くことが出来ない。つまり、再利用できない画面になってしまう。

また、このような「知り合い」関係があると、プログラミングを行う場合にも問題が発生する。この設計書をそのままの形でプログラミングしようとすると、ソースが「循環依存」してしまうのだ。循環依存とは、「A を作るには B が必要だが、B を作るには A が必要だ」ということである（※１）。いったい A と B のどっちから作ったらいいのだろうか？

循環依存に寛容なプログラミング言語もあるし、循環依存を回避するテクニックもある。また、理由があって、あえて循環依存させるような設計をすることもある。しかし、積極的にそうすべき理由がないのであれば、循環依存するような設計は避けるべきである。

こうした考え方が当てはまるのは、ここで上げたような「画面」同士の関係だけではない。関数やクラス、パッケージやライブラリなど、プログラムを構成する要素は小さな単位から大きな単位までいろいろとあるが、どこにでも当てはまるのである。

★
さて、詳細画面と一覧画面を「知らない」という設計にしようと思うと、詳細画面の設計書に「一覧画面」という言葉は出てきてはならないということになる。つまり、冒頭の設計書はこうなるだろう。

一覧画面
・画面を開くときの処理
　データベースから全ての商品の ID と名称を取得し、表形式で表示する。
・一覧の行がダブルクリックされたときの処理
　ダブルクリックされた行の ID を渡して、「詳細画面」を開く。

詳細画面
・画面を開くときの処理
　呼び出し元から渡された ID をキーにして、データベースから商品の詳細情報を検索し、表示する。