dJUnitでカバレッジテスト

　自分が書いたプログラムをdJUnitでカバレッジのテストをするのが楽しい。

　カバレッジを目で見ることができることそのものが楽しい。

　情報処理試験で、分岐網羅やテストについて概念や用語を習うけれど、実際に理解して使いこなせている人はどれだけいるのだろうか？
　カバレッジのテストが重要なのは、プログラムの品質そのものに直結するから。

　JUnitのテストプログラムを書くのは簡単で、むしろテストケースを洗い出す方が難しい。
　テスト仕様書にあるテストケースで全てのステップを通過しているか、更には全ての分岐を通過しているか、を頭の中だけでイメージするのは、ステップ数が多くなるほど漏れが起きやすい。

　dJUnitを使うと、JUnitのテストメソッドを実行後、テストで通過していない行にマーカーが付く。
　少なくとも、マーカーを全て消すようにテストメソッドを実装していく。その作業は結構楽しい。

　テストプログラムが先にありきの本来のテスト駆動のやり方ではないけれど、今のやり方は、既に作られたプログラムが存在し、そのプログラムの分岐を全て網羅するようにテストメソッドを実装していく。
　設計力がしっかりしている人は、最小個数のテストケースで全ての分岐を網羅できるが、漏れがないことを証明するのは結構難しい。
　少なくとも、dJUnitのように網羅した箇所をレポートで自動生成できるなら、かなり手間は省ける。

　Eclipseが出現して４年以上経つけれど、色んなツールが出ていて、開発環境が以前と比較にならないほど整ってきている。
　特にテスト系ツールは、プログラムの品質に直結するから、最重要だ。

　しかし、Java＋Eclipseに比べると、他の言語の開発環境は使いづらい。。
　Rubyも何とかしてくれないかな。

Web 2.0で一番重要なのは価値あるデータベース

　ベンチャー企業の代表者が解くWeb 2.0と経営の本質という記事で、「Web 2.0で一番重要なのは価値あるデータベースだ」という意見が載っている。

　Googleにしても、Amazonにしても、自分たちが持つ地図や商品のデータベースへつなぐAPIを公開することで、自分たちのサイトへのリンク、更には訪問者を増やすというビジネス手法を取る。

　この発想の根本は、データベースが重要なこと。そのデータベースへリンクさせるためにAPIの公開が必要だし、サーバーにアクセスが集中しても、その負荷に耐えられる仕組みが必要。

　その公開手法はオープンソースとは違うけれど、依然とは違い、自分たちのシステムの情報（の一部）を公開する方が実は利益になるという逆説。

　今後、インターネットを使ったビジネスの発想は、Webを通じて自社のデータベースへリンクするAPI公開にあるのかもしれない。

デザインパターン再考

　各人でバイブルと呼んでもいいぐらい影響を受けた本、そして愛用している本はあると思うが、自分にはGoFの「オブジェクト指向における再利用のためのデザインパターン」が相当するように思う。

　仕事で手が空いている時は、この本のCD-ROMに付属していた抜粋HTMLをよく読んでいるからだろう。

　デザインパターンとは、「より良いインターフェイス設計手法」と呼ぶことも出来る。
　23個のパターンは、粒度の違いはあれど、いずれも珠玉の概念だ。
　
　そもそもデザインパターンに惹かれるのは何故だろう？
　それは、似たようなインターフェイス設計を何度も行った経験があるから。
　詳細設計やプログラミングでデジャブをいつも感じるから。
　リファクタリングと絡めると理解しやすい。

　23個のデザインパターンは、個人的には「ポリモルフィズム」「仲介コントローラ」「インスタンス管理」の3種類で分類できると考える。

１．殆どのパターンはポリモルフィズムの原理を使っている。

　ポリモルフィズムの意義は条件分岐の除去だ。
　実際には、複雑なIF文を呼び出し側から呼ぶ側へ移動することにある。この手法を徹底すると、複雑な条件分岐のアルゴリズムがModelからViewへ移るため、最終的にはリフレクションで条件分岐を全て除去できる。

　具体的には、ポリモルフィズムの対象オブジェクトは、アルゴリズム(Strategy)、状態(State)、要求(Commnad)、再帰(Composite)、コンテナ(Iterator)、文法処理(Interpreter)によって観点が異なるだけ。

　2個のパターンを組み合わせたパターンもある。
　DecoratorはCompositeとStrategyを組み合わせたパターンだし、Chain of ResponsibilityはDecoratorにイベントの概念を追加したパターンと言える。

　特異なパターンがVisitorだ。
　以前は「Visitorパターンはどこで使うのだろう？」と疑問に思っていたが、一言で言えば「マトリックス型のポリモルフィズム」。
　つまり、Visitorクラスはswitch文をクラス化したものとして、その構造が自然に現れる。

２．仲介コントローラを導入するパターンは、複雑な処理を委譲する原理を使う。
　仲介コントローラを導入する意義は、処理の複雑さを凝集度の観点から、一つへまとめたり2個以上へ分割することだ。

　仲介コントローラの対象オブジェクトの役割が、インターフェイス適合(Adapter)、処理の仲介(Proxy)、Controllerの共通インターフェイス(Facade)、オブジェクト間の複雑な通信制御を一つにまとめるもの(Mediator)などと観点が異なる。
　
　最も奥が深いのは、Observerパターンだ。Observerパターンはイベントの概念そのものだが、Multicastパターンで実装されることが多い。
　JavaとC#ではプログラミングスタイルが大きく異なる部分でもある。

３．インスタンス管理を導入するパターンは、用途によって異なる。

　ポリモルフィズムと組み合わせ（AbstractFactory）、コンストラクタ置換(FactoryMethod)、唯一のインスタンス生成(Singleton)、インスタンス複製(Prototype)、インスタンスの履歴保持(Memento)などがある。

　デザインパターンは、実装言語によって大きく異なる部分がある。
　Java、C#、VB、Rubyなどで書いてみると、実装言語の制約でデザインパターンを使えない時があったり、デザインパターンそのものの実装が長くなったりする。
　実装言語の比較によって、自分なりのデザインパターンの解釈を今後、連載してみたいと思う。