前回は、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 なんです。）

» 続きを読む

良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。

ぼくは、

   EoT(*1)の高い設計が、よいオブジェクト指向設計である。

と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、

• 継承という言語機構は、Mockを作るためのもの

• 実装ではなくインターフェイスに対してプログラミングするのは、テストしやすくするため
• よいモジュール分割とは、テストしやすいモジュール分割である
• 循環依存性を排除するのは EoT のため
• DI(Dependency Injection)は、EoTのためのツール

ちょっと本末転倒に感じられるかもしれない。しかし、他の業界ではテスト容易性をもっと重視している例が多い。例えば、コンピュータのハードウェアは「テストが可能な設計」になっていることが普通だ。テスト用のジャンパーは設計に折り込み済みだし、メモリにはパターンの記録とチェックができる機能がある。

写真は、テレビ局が流す、朝の「テストパターン」。これは、テストが織り込まれたシステムデザインの例だ。テレビプログラムは、最初からテレビの受像機をテストする、という機能を折り込み済みなのである。テストが、最終的な顧客価値の検証になるのだから、テストができない設計など、意味がないのではないか。

他にも、ソフトウェア以外でテストを「折り込み済み」の設計を見つけたらぜひ教えて欲しい。

[1] EoT： Ease of Testing、テスト容易性。Testability に替わる平鍋の造語

(参考) アジャイル開発の奥義

http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/xpjp-22