[ruby-list:33235] " 差分ベースモジュール " in Ruby

中島@ブレーンです。

http://www.ogis-ri.co.jp/otc/hiroba/technical/MixJuice/
で、"差分ベースモジュール"という手法が提示されています。この言葉はこの記
事で知ったのですが、Walrusの実装で私はこれと似たようなことをRubyで行なっ
ています。

これについて、みなさんの意見やアイディアをいただけたらと思って、まとめて
みました。

○ 差分ベースモジュールとは

詳しくは、上記の記事に譲りますが、簡単に言うと、一連のクラスに「ちょっと
ずつ」メソッドを追加していくことだと思います。

普通のオブジェクト指向言語では既存のクラスに機能を追加する場合は継承を使
いますが、is-a関係を表現するための継承と、差分を実装するための継承が混在
すると、構造が複雑になります。

例えば、親クラスPと子クラスCがあったとします。両者に何かメソッドを追加す
る場合、Pを継承してP2、Cを継承してC2を作成し、P2,C2に新しいメソッドを追
加することになります。

  P  →  C                  →: is-a関係を表現する継承
 ↓     ↓                  ↓: 差分を実装するための継承
 P2     C2         

この図の↓で表わされている関係を別のメカニズムで表現しようと言うのが、
"差分モジュール"という考え方だと思います。

○ Rubyにおける差分モジュールもどき

上記の記事では、Java言語をベースにMixJuiceという新しい言語を設計して、
"差分モジュール"を実現していますが、Rubyではクラスが閉じていないので、ソー
スファイルを単位として似たようなことを行なうことができます。

なお、Rubyのmoduleとここで言うソースファイルベースの差分モジュールのエミュ
レーションとは別ものです。ややこしいので、Rubyのmoduleは英語でmoduleと書
きます。

Rubyによる差分モジュールの実現は次のようになります。

  ソース1
-------------------------------------------
   class P
     ...
   end

   class C < P
     ...
   end
-------------------------------------------
  ソース2
-------------------------------------------
  require ソース1

  class P
    def xxx
      ...
    end
  end

  class C
    def yyy
      ....
    end
  end
-------------------------------------------

ソース1が基本モジュールで、ソース2がそれを"継承"した子モジュールです。

xxxとyyyが関係が深く、他のメソッドと独立しているとすると、xxxやyyyを使わ
ない人は、ソース1のみを使用し、xxxやyyyを使用する人はソース2を使用します。

ソース1に直接メソッドを追加していくと、ソース1がどんどん大きくなっていく
し、追加した機能の不具合がそれを使用しない人にも影響する可能性があります
が、このように分割していけば、ソースがコンパクトで関連する機能が近くにあ
りますから、メンテナンスが楽です。

○ Walrusでの使用例

Walrusは静的なHTML生成ツールとして開発して、アプリケーションサーバに発展
しました。そして、最初の生成ツールの段階で、次のようなクラスの階層ができ
ていました。

WalrusObject   →   Folder
               →   DocumentFIle
                    →  HtmlDocument
                        → DiaryDocument
                        → ManualDocument
                        → ....(各アプリケーションのドキュメント)
               →   BinaryFile
                    →  ImageFile
                    →  ArchiveFile

これを拡張してアプリケーションサーバにしたわけですが、各階層のそれぞれの
クラスにちょっとずつメソッドを追加する必要があります。ここでどうするか悩
みました。

(1) クラス階層再設計

既に完成して(個人的に)運用しているHTML生成ツールが動かなくなるのは避けた
かった。また、HTML生成ツールとしてもアプリケーションサーバとしても対象の
論理的なモデルは同一なので、クラス設計はこのままでよいと思った。

(2) クラスにメソッドを追加していく
追加するメソッドの行数は少ないが、いろいろなクラスにちらばっていて、相互
の関連が深い。デバッグのために、あちこちのソースをちょっとずつ見る必要が
ある。

(3) "差分モジュール"
追加機能と既存機能が分離され、開発、デバッグがしやすい。

ということで、(3)を選択しました。

具体的には、walrus.rbが基本モジュールで、rope.rbがそれにアプリケーション
サーバの機能を追加するモジュールです。rope.rbで追加したクラスもあります
が、ほとんどはwalrus.rbに定義されているクラスにメソッドを追加しています。

なお、追加するメソッドはmoduleにまとめて、既存のクラスにMixinしました。

○ もどきの限界、問題点

Walrusのソースは機能単位に分割されていていて、ssc.rbがセッション管理、
db.rbがデータベースアクセス機能・・・というふうになっています。しかし、
上記の一箇所以外では、差分モジュールの手法は使わず、新規のクラスの定義だ
けにしています。

本当は他のソース(機能追加)でも、差分モジュールで既存のクラスに機能を追加
した方が、うまくまとまる場合もあったのですが、自分ではこれは「変なやり方」
と思っていたので、自重してしまいました。もっと早く、この論文を見ていたら
結果が違ったかもしれません。

ただ、ひとつのクラスが複数のクラスに分割されているというのは、気分的に落
着かないものです。特に、名前の衝突が問題になります。

MixJuiceでは可視性の概念がJavaからかなり拡張(整理？)されているようです。
"差分モジュール"をダイヤモンド継承している時、兄弟関係にあるモジュールで
名前が衝突していても大丈夫みたいです。

上記のもどき手法で、複雑な差分モジュールの継承関係(ダイヤモンド継承)も可
能だと思いますが、名前の衝突が起きると悲惨なバグになります。

○ 質問

今後、Walrusを開発していく時に、差分モジュール方式の機能別ソース分割のま
までよいのか、クラス単位に整理しなおした方がよいのか迷っています。それで
お尋ねしたいのですが、

・ Rubyでこのような"差分モジュール"を使っている例は他にありますか？
・ 名前の衝突を避けるよい方法はないでしょうか？
・ 実行時コスト的な観点から、不要なメソッドを大量にloadする負荷について
   どうなのか？
・ 全体的にこのような手法について、みなさんはどう思いますか？

-- 
「stableでなければ生きていけない。unstableでなければ生きてる意味がない」
中島 拓 (株)ブレーン 研究部 ([e-mail])
http://www.brain-tokyo.jp/~research/koutetu/