> 長谷川＠テクノポートです。
こんにちは，寺田＠東工大 です．
レスが遅れて申し訳ありません．
大変丁寧なコメントをありがとうございます．
> 多くの人が考えている再利用の中にコードの再利用があります。
> しかし、パターンでもそういう再利用を目指していません。
> デザインパターンは比較的ポピュラーなので読まれたことがあるかも
> 知れませんが、これとて単純に再利用と言ってしまうと誤解が生じます。
>
> 再利用可能なものを作るというようりも、adaptorが典型ですが、
> 既にあるものを変更せずに使うという、再利用部品ではなく、
> 再利用技術になっていると思います。これは、通常言われている
> 再利用とは少し違うと思います。
私の考えでは，デザインパターンは「経験」の再利用（と共有）だと思ってい
ます．デザインパターンの偉大な点は，「経験」という形のないものに名前を
付けたことだと思います．実生活での会話においても，名前がついているもの
に関してはコミュニケーションが非常にスムーズですよね．逆に，名前がまだ
ない概念を説明しようとすると，とても苦労してしまう．そういう意味では，
「名前」というのは「概念の説明」を手軽に再利用するための道具になってい
ると思います．
確かに，たまたま adaptor は既存コード再利用のための技術となっています
が，デザインパターン全てが再利用技術だとは思いません．
例えば Composite パターンはどうでしょうか？ 既存のものを再利用するため
に Composite パターンを適用する，というのはおかしいと思います．Composi
te パターンそのものがあらゆる場所で再利用されると考えた方が自然なので
はないでしょうか．また，「Composite パターン」という名前のおかげで，開
発者間で知識が整理されて，知識の再利用が円滑になると思います．
> そういう意識はいいと思います。
> しかし、実情を見るととてもそういうふうには見えません。
> まず、とにかく助けて欲しいとわらをもつかむプロジェクトが
> 多すぎます。そこで、他のプロジェクトが再利用可能なものを
> 提供してくれたら...となります。
>
> これは、現場でちょっと聞けば確認できます。
> まず、自分達で作ろうという気がほとんどありません。
> それは用意されるものと考えられています。
>
> また、逆に再利用部品を提供する側を考えても、利用者のことを
> 考えているというよりも、自分達の考えを単に押し付けているだけ
> に見えることが多いです。これも確認可能です。
> 提供したものが、利用される場でうまく適合するかを追跡
> 調査する人など皆無の状態です。
>
> こういう状況では、神頼みか蜃気楼という程度のものです。
> そして、XPにはそういう状況を打開してくれるかもしれない
> という期待を個人的には持っています。
・・・なんだか，随分現状に対して否定的なんですね．
仮に現状の「再利用」が蜃気楼であったとして，どうして XP がそういう状況
を打開するものなのか，教えて頂けないでしょうか？ 上記の文脈からは，長
谷川さんが XP に期待する理由がうまく読み取れないです．
私には，「再利用」を簡単にあきらめてしまうことはできません．
自分で作った行列・ベクトル演算ライブラリなどは，何度も繰り返し再利用し
ましたし，その結果として再利用の便利さを実感しました．その実感は決して
「蜃気楼」ではなかったと思います．
ですから，今後もぜひ再利用を心がけていきたいと考えています．確かに再利
用は難しいのかもしれません．しかし，だからといって諦めてしまうのではな
く，どうすれば再利用という名の暴れ馬を飼いならすことができるのか，考え
るべきだと思っています．
> それと、少し気になるのが、もしかしたら統一化のようなことを
> 考えられているのか、です。または、数少ない優秀な、もしくは
> 再利用可能な部品を使って、構築すると言ったような。
>
> やかんひとつとっても、大きいもの、小さいもの、材質の違うもの、
> 形の違うもの様々です。昔は石鹸がオールマイティの時代がありましたが、
> 今では、ハンドソープ、ボディソープ、シャンプ、キッチン洗剤、バスXXX
> など数え上げるのが困難なほどです。これらをひとつのもので済ます
> ことはもうできないでしょう。
>
> これらはより文脈に適合するために細分化されたわけですが、
> おそらくソフトウェアでも同じ状況が生まれてくると思います。
> ソフトウェアに関わっているものにとっては、大変なことですが、
> といって単一化、統一化という手段で適応していけるとは思えません。
> ＃面白い例は、漢字変換ソフトやフォントと言ったものが、
> ＃淘汰されたと思っていても、携帯電話の中で生きていることでしょうか。
>
> しかし、考え方や構築の仕方といったものは、ある程度単純化する
> ことができます。但し、そこにはそういった多様なものを生み出す
> 可能性を持ったものでないと意味はないと思います。
> ＃全く同じものしか生産されない仕組みはどのみち壁にぶつかると。
そうですね．
私も，巨大な「統一された」ライブラリはやっぱり良くないと思います．比較
的小さなライブラリから様々なクラスを「つまみ食い」できる状態がベストで
はないでしょうか．言い換えれば，「つまみ食い」ができるようなライブラリ
作りを心がければ，再利用は十分可能だと思います．
クラスも，あまり巨大なものは嫌がられますよね．responsibility が過多に
なっているクラスはリファクタリングによって複数のクラスに分割するべきで
しょう．同様に，ライブラリにも responsibility という考え方を導入するべ
きかもしれません．つまり，ライブラリが責任過多になった場合には，リファ
クタリングにより複数のライブラリに分割するわけです．こうすれば，ライブ
ラリも XP 的なインクリメンタルな開発が可能かもしれません．
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Yuichiro TERADA
Tokyo Institute of Technology,
Kobayashi/Todoroki Lab.
+ yterada@....jp
+ http://ginza.mes.titech.ac.jp/~yterada
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/