読者です 読者をやめる 読者になる 読者になる

再利用の二つの軸

OSGi

ゆうすけさんから聞いた、モジュール指向開発の「再利用の二つの軸」が素晴らしかったのでまとめます。ただ、ブログに書いている時点で、自分がモジュール指向開発を進めている経験もあって、その考えも練り込まれてしまっているので、その辺りはご了承を。あと、モジュール指向は、コンポーネント指向とも読み替えられるので、その辺は適当にどうぞ。
モジュール指向開発の再利用には二つの軸があります。それは時間軸と、空間軸です。時間軸は、モジュール毎に独立して開発を進め、改版していくことを指します。システムを構成する要素として、時間軸上で再利用が繰り替えされる、という意味での再利用です。対して空間軸は、特定の機能毎にモジュールを再利用することを指します。一般的に、モジュールを再利用する、という話になると、後者を指すことが多いです。先日のエントリでは明確にどちら、という話が書いてませんでした。ですが、どちらかというと前者、時間軸上で再利用を述べたつもりです。再利用、という話をすると、どうしても空間軸上の再利用が対象になってしまうし、自分も、空間軸での再利用を混ぜたまま話を書いていました。わかりづらくてごめんなさい。
さて、OSGiによるモジュール指向開発は、Bundle毎に独立しているという性質のため、基本的に依存しているBundleにのみ影響されます。そのため、あるBundleに手を入れたからといって、全てのBundleをテストしなおす必要はありません。依存する部分との組み合わせだけでよいです。例えば、Quick JUnitの最新版をリリースからといって、Eclipse Foundationが行っているテストをすべて僕がしなければならない、なんて事はないですし、Eclipse Foundationがテストをしてくれるなんてこともないでしょう。要するにモジュールが独立しているのであれば、変更が影響される範囲のみ、テストをすればよいのです。言い換えると、あるモジュールをシステムで使いつづけ、それぞれ独立して開発し、システムへの影響を限定できると言い換える事ができます。既存のシステム開発だと、一部分のみ更新する、という運用がなされたとしても、「影響範囲が分からない」ため、原則的に全てテストしなければならない、となると思います。時間軸での再利用のしやすさ、とは、こういう面を指します。そして、新規開発から、継続開発、保守、という流れの中にあるエンタープライズ開発でも、一部分だけ更新、テストしたいという要求は確かなものだと思います。
ただ、時間軸上で再利用されたモジュールは、他の似たようなシステムへ転用したくなるもんだと認識しています。長く手を入れるられことなく、作り直さないでもよいモジュールであれば、機能やAPIが安定しているので、他のシステムへの転用が視野に入れられるはずです。そして、空間的な再利用で勘違いされてしまうのが、転用できるのは、あくまで用途が特定できていて、モジュールがそれに合致している場合のみです。EJBのビジネスコンポーネントが流通しなかったのは、EJBの利用者が、用途を理解し、システムに導入するよりも、自分たちでビジネスロジックを書いた方がコストが安かったためだと考えています。現在、販売されているコンポーネントで、成功しているのが、UIのみだ、ということからも、この考えは間違っていないでしょう。UIは用途が特定され、かつ分かりやすい。その上高度なUIの構築は非常に高コストなため、自分たちで作るよりも安いからです。
そしてこの、「空間的な再利用がうまくいかなかった」から、これからもビジネスコンポーネントがはやらない、というのは早計に思えています。それはまた別の機会に。
あと、OSGiを使えば、モジュール設計技法が身につく、とか、そんなことをいいたいわけじゃないので、よろしくです。