『オブジェクト指向入門』という本がある。今は第2版が出版されていて、原則・コンセプトをテーマにしたものと方法論・実践をテーマにした二分冊になっている。この本はオブジェクト指向によるソフトウェア構築 (Object-Oriented Software Construction) とはなにかについて、緻密に基礎の基礎から話を積み上げ、その全体像を描き出す他にない名著だ。ぼくはまつもとゆきひろさんが推薦する本として最優先に挙げていたのを見て当時出ていた第一版の翻訳を買って読んだ。

最近になって必要があって読み返して驚いたのだけど、今でも自分の設計の指針となっているベースはとことんこの本の内容だった。技法ではなく、設計をするというときに考える思考の観点はこの本からもらったもので、その観点を実現するにはどんなことを理解し考えないといけないかをその後学んで実践し続けてきたのだということに気付くことができた。ソフトウェアを設計するということができるようになるために、方法論を理解しその実践を通して設計ができている状態を目指しているような人にこそ読んでみてほしい本だ。

この本は丁寧に理論が構築されているので、いきなり美味しいところから入ったりはしない。最初はソフトウェアの品質から始まる。

工学の目的は品質である。したがって、ソフトウェア工学は、品質の高いソフトウェアの生産を意味する。

自分の設計の指針となっているベースと書いた内容は第 3 章にある。ここでは、モジュール性をテーマにその 5 つの基準 (criteria)、5 つの規則 (rule)、そして 5 つの原則 (principle) が説明される。

5 つの基準

基準は「モジュール性がある」と呼ぶときに満たしている必要がある基準を挙げている。

分解しやすさ (Decomposability)
組み合わせやすさ (Composability)
分かりやすさ (Understandability)
連続性 (Continuity)
保護性 (Protection)

5 つの規則

これらを保証するために守らなければならない 5 つの規則というのが規則として挙げられているもので、これが「設計の指針となるベース」として設計のことを考えるときに常に頭の中で考えている観点そのものだった。

直接的な写像 (Direct Mapping)
少ないインタフェース (Few Interfaces)
小さいインタフェース (弱い結び付き) (Small Interfaces (weak coupling))
明示的なインタフェース (Explicit Interfaces)
情報隠蔽 (Information Hiding)

直接的な写像

ソフトウェアシステムというものは何らかの問題領域の必要に対処しようとする。ある問題領域を記述する良いモデルがある場合、ソフトウェアによって提供される解決手法の構造と、モデルとして表現される問題の構造の間の写像 (マッピング) を、明快に保つことが望ましいことに気づくはずだ。このことから次の第 1 の規則が導き出される。『ソフトウェアシステムの構築過程で考案されたモジュール構造は、それに先立つ問題領域のモデル化の過程で考案された任意のモジュール構造との互換性を維持していなければならない。』

少ないインタフェース

少ないインタフェースという規則により、ソフトウェアアーキテクチャに含まれるモジュール間の通信チャンネルの全体数を限定することができる。『すべてのモジュールができる限り少ない数のモジュールとの通信で済むようにすべきである。』通信はモジュールの間でさまざまな方法で発生する。モジュール同士が呼び合う (それらがプロシージャの場合) こともあるし、データ構造を共有することなどもある。少ないインタフェースの規則は、このような接続の数を限定する。

小さいインタフェース

小さいインタフェース、すなわち、「弱い結び付き」の原則はモジュール間の接続の数ではなくサイズに関係する。『2 つのモジュールが通信する場合、そこで交信される情報はできるだけ少なくするべきである。』電気工学の言葉を借りていえば、モジュール間の通信チャンネルの帯域幅は限定されていなければならない。

明示的なインタフェース

この 4 番目の規則では、モジュールの社会に対する全体主義体制の強化を一歩進める。すべての会話を少数の参加者に制限し、言葉もわずかな言葉を交わす程度に限ることを強制するだけでなく、会話は公に大声で (！) 行うことを要求する。『A と B の 2 つのモジュールが通信するとき、必ず、そのことが A または B あるいはその両方のテキストから明らかに分からなければならない。

情報隠蔽

情報隠蔽の規則は次のように記述できる。『どのようなモジュールであれ、モジュールを設計する人は、そのモジュールの属性の中からいくつかの属性をそのモジュールに関する正式な情報として選択し、顧客モジュールの作成者がその情報を利用できるようにしなければならない。』この規則を適用することによって、すべてのモジュールは何らかの公式な記述、あるいは公開 (public) 属性によってのみ回りの世界 (つまり、ほかのモジュールの設計者) に認知されることが期待される。もちろん、モジュールそのものの全テキスト (プログラムテキスト、設計テキスト) を使っても説明書としての役割は果たす。そうしたテキストはモジュールの正しい姿を反映しているが、それはモジュールそのものなのだから当然だ！　しかし情報隠蔽の規則は、一般的にはそのようなすべてを公開するといったやり方をとるべきではないと告げるものだ。説明書はモジュールの属性の一部だけを述べるべきで、残りの部分は公開しない、つまり非公開 (secret) にするべきである。なお公開、非公開の属性という代わりに、「エクスポートされた属性」、「プライベートな属性」ということもできる。モジュールの公開属性はモジュールのインタフェース (interface) としても認識される (ソフトウェアシステムのユーザインタフェースと混同しないように)。

5 つの原則

これらの規則からソフトウェア構築の 5 つの原則が導かれる。

言語としてのモジュール単位 (Linguistic Modular Units) の原則
自己文書化 (Self-Documentation) の原則
統一形式アクセス (Uniform Access) の原則
開放/閉鎖 (Open-Closed) の原則
単一責任選択 (Single Choice) の原則

これらは方法論への要件となってくるので、これはこれで面白く「開放/閉鎖原則」や「単一責任選択の原則」のような重要なものも含まれるのでぜひ読んでみてほしいところだけれど、常に頭にあり思考の基礎になっているのはやはり 5 つの規則のほうだなと思う。ほぼすべての自分の書いているコードについて、5 つの規則に照らし合わせてどうだからこうするという判断を自分の中でしている。コードレビューをするときもそうで、指摘や質問のベースにはこの規則があり、その観点でこう思うけれどどうかということを書いていることが多い (たぶんほとんど全部そう)。

この他にもオブジェクト指向入門から学んだことは多いし、他の書籍から学んだ方法論もたくさんある。それでも、どうやら自分の頭の中ではそのそれぞれはこの 5 つの規則の観点でどんな風にモジュール性のある状態を保つのに寄与しているのかという見方をしている。モジュール性の高いソフトウェアを実現するために、5 つの規則を守るやり方はいろいろあり、その方法論を学び使っていっている。

実際「オブジェクト指向入門」の二冊だけをとっても、原則・コンセプトが 904 ページ、方法論・実践が 754 ページととてもここまでの内容だけで設計を語れるわけではないのだが、それにしても他の知識を語るためのかなり重要な基礎として考え続ける価値のある内容だと思う。

補足しておくと、今の時代にオブジェクト指向プログラミングを学ぶのにこの本が最適かというとそうではない側面はいくつもある。クラスベースの話が中心で、それによって学びが薄くなるオブジェクト指向プログラミングの良い側面はある。それでも、ソフトウェア構築とはなにかについての変わらぬ地盤を築くための本として今でも重要な役割を担える本だと思う (方法論・実践にある「抽象を探す」なども設計をするとはそういうことかと一つ視界が開けるような刺激的なトピックでよい)。