「変更しやすい」ことが、良い設計 (EoC=Ease of Changing)

前回は、EoT(Ease of Testing: テスト容易性)によってよいオブジェクト指向設計を再定義したい、という表明をした。今回は、二本目のナイフを抜きたい。キーワードは、EoC(*1)(Ease of Changing)、変更容易性だ。

この記事では、

   EoCの高い設計が、よいオブジェクト指向設計である。

と主張したい。設計品質の中で、「変更容易性(EoC)」を最上位と見る。

ここ10年のオブジェクト指向の最大の失敗は、「再利用性」をその最大の価値、として説明しようとしてきたこと。そして分かったことは、再利用がその努力コストに見合う効果がでることは極めて稀であること、また、テクノロジではなくソーシャルな活動が再利用に効くこと、さらに、コードの再利用ではなく、ナレッジの再利用（例えばパターン）の方が、まだ可能性があるということ（少なくとも2005年のコンテクストでは）。

再利用性ではなく「変更容易性」に注目すべきだ。Kent Beckの "Embrace　Change"であり、Bertrand Meyer の "Build Software for Change" である。変更容易性を高くしてソフトウェアを作れば、再利用性よりもコスト削減できる可能性が出てくる。

EoCを中心に考えて、オブジェクト指向とは何か、を導き出そう。オブジェクトを切り出すときに、「責務」とか「凝集度」と従来言われている「概念の輪郭と中心を決めるもの」を「変更要因」と呼びかえる。外部の変更要因をカプセル化してクラスとするのだ。1つの変更要因が、1つのクラスに閉じられるように。変更を伝播させてはならない。

また、アーキテクチャは、変更の頻度、または、変更の安定度にしたがってクラス群の大域構造を決める活動だといえる。変更周波数を分析し、その順にパッケージを並べる。こうして、変更周波数の高い方が低いほうに依存するようにする。MVCやBCEというアーキテクチャルな分割は、これに意味を付与したものだが、EoC的に考えると、この本質は変更要因の（時間ドメインでの）周波数だ。

大きな外部の変更は大きな内部変更で、小さな外部の変更は小さな内部変更で済ませられること（小さな外部の変更が、大きな内部の変更にならないこと＝Meyerのアーキテクチャ連続性）。この技術がオブジェクト指向設計であり、そのためには、ソフトウェアの外部の問題構造とソフトウェア内部の解構造がダイレクトマッピングされている必要がある。すなわち、外部の言葉で内部が設計されており、外部の変更要因が、うまく内部の対応部分で吸収できる必要がある。

まとめよう。EoCにしたがってソフトウェア設計を捕らえると、

• ソフトウェア外部の変更可能性を分析して、ソフトウェアの大域構造を決める
• ソフトウェア外部の個々の変更要因をクラスとして取り出す（そのために、）
• ソフトウェア外部の問題領域の言葉で内部のモデルを構築する

となる。

[1] EoC： Ease of Changing、変更容易性。Modifiability に替わる平鍋の造語

（言い忘れましたが、この日記の写真は、品川のある「蕎麦屋」の通路にある、造形です。 人口竹、玉砂利、行灯、だけで、これだけの造形ができるのですが、実はこれは「作りつけられていない、アドホックに作られた構造」なんです。飽きたり、通路が狭いと感じられたりした時は、簡単にまとめて変更することもできます。ぜんぶ取っ払ってしまうことだってできる。大域構造にくくりつけられていないので、大域構造の寿命より短いライフサイクルで変更できます。 この造形は、美しいし、built for change なんです。）

咳さんにmixiでコメントされて気づきましたが、EoCを高めるには、

• 変化を予測し、それに備えること
• 変化は予測できない、と考え、シンプルに保つこと

の２つの戦略があります。前者はフレームワーク的、ChangeCase的考え。後者は、XP的YAGNI的考え。両方は、バランスの上に成り立つものだと思っています。

もう１つ、「一貫性（統一性）を保つ」こと、読みやすさを保つこと（よい名前を選ぶこと）が非常に重要です。たしか、Rubyのまつもとさんは、ある機能を入れるかどうか、という判断をするときに、「それによい名前がつくかどうか」というのを１つの判断基準にしている、と聞いています。

アジャイルのように、「変更」を基本（すべての機能追加は変更）とするプロセスでは、変更容易性がその設計を使うチームの生産性そのものになりますね。いつも保守モード、というイメージです。そういう意味で、「運用が最上流」という天野さんの考えは、とても現実的です。

http://www.objectclub.jp/ml-arch/magazine/98.html

もらったトラックバックにコメントを追記します。

http://munepi.cocolog-nifty.com/blog/2005/08/post_2f26.html

確かに、STLは再利用です。（実はぼくはStepanovのSTLの設計が大好きで、オブジェクト指向でない方向での抽象化のやり方のお手本だと思っています。）

例えば、strlen() 関数も再利用です。問題は、標準化が起こった水平ドメイン（STLやstrlen()、いってみれば、アルゴリズムやコンピュータをどう使うか）は再利用されているが、企業内とか、グループ内とか、プロジェクトを超えて、垂直ドメイン（業務などの再利用。例えば、EJBがやろうとしたレベル）がほとんど起きていない点です。