長谷川＠テクノポートです。
----- Original Message -----
送信者 : "Y.Terada" <yterada@....jp>
送信日時 : 2001年 3月 5日 月曜日 午前 05:41
> 寺田＠東工大 です．
> 長谷川さん，こんにちは．
> 太田さん，はじめまして．
>
> すごく変な時間にメールかいてます．
> 卒業に際し，大学の PC から必要なファイルを整理してバックアップしていたので
> すが，思いのほか時間がかかってしまいました．
これって、前日から午前５時のことですか？
＃でも、若いんですから...(^^。
> > やっぱり、パターン＝デザインパターン、そして
> > パターンランゲージって何？という状況が少しつらいです(^^。
>
> 申し訳ありません．そのとおりです．
> 「パターン」は意味が分かってる（つもり）のですが，「パターン・ランゲージ」
> という言葉は聞いたことがあるだけで意味が分かっていません．
> 勉強不足で申し訳ないです．
いえ、いえ、この場合は、期待する方がどうかしています(^^;。
＃まだまだ知らない人の方が多いので気にしないで下さい。
> ですが，ようやく，長谷川さんのおっしゃっていることが分かり始めたような気が
> しています．何となく，ですが．私の理解を書いてみますので，長谷川さんのご意
> 見を誤解している部分がありましたらご指摘ください．
良かった。余り人に教えるのは上手くないので。
読んでみます。
> --- 以下，私の理解 ---
>
> （パターン等の）再利用，というと，本質を見ることなく型にはめていくだけで素
> 晴らしい製品ができる，と言っているように感じられるが，それは正しくない.
>
> 既存の部品やパターンをただ機械的に並べていくだけでは，いつまでたっても真に
> 素晴らしい製品には辿り着けない．既存部品を利用したり，既存のパターンを参考
> にしたりすることはあっても，それだけでは成功しない．様々なシステムの仕様は
> すべて異なるものでありどれ一つとして同じものは存在しないのだから，すべての
> システムに適用できる画一的な部品やパターンは存在しない．
>
> 良いシステムを作るためには，そのシステムに固有の「本質」を見抜き，システム
> に合わせて柔軟にパターンを適合させていく必要がある．このように，システムに
> 合わせてパターンを適合させるような設計をするためには，パターンを名前から想
> 起される即物的なイメージだけで捉えていてはいけない．個々のパターンの意味や
> 本質をしっかりと理解しておく必要がある．
>
> 従来のオブジェクト指向方法論では，パターンの本質的理解を促進しない．あるい
> は，機械的な適用を促している．つまり，将来の変更や拡張を完全に予測した柔軟
> 性の高い設計を行い，それ以降はフレームワークに機械的に従うだけで良いシステ
> ムが構築できることを目指している．そのため，設計者は常に，自分の設計が十分
> な柔軟性を持っているものなのか不安にさらされることになる．
>
> XP はこのような状況を打開するものである．XP は YAGNI の原則などにより，将来
> の変更を予測した柔軟性を持たせることに対して否定的である．パターンは参考に
> するが，部品やパターンの画一的，機械的な再利用を否定する．これは，逆にいえ
> ば，システムごとに固有の本質を見抜き，そのシステムに最も自然な設計を行うこ
> とを促進している．
>
> すなわち，XP はシステムから機械的な再利用を排除し，ごく自然に「本質」へと辿
> り着く道しるべとなっている．「XP で再利用できますか？」という問いに対しては，
> 「機械的で間違った再利用を排除し，真に有用な本質の再利用を促進することがで
> きる」というのが答えとなる．XP における再利用とは，「部品だから」「パターン
> だから」という形式ばったものではなく，もっと自然に導入されるものである．
>
> --- 以上，私の理解 ---
うう、素晴らしい。これだけ上手くまとめられたら、思わず、
今まで書いてきたのはなんだったんだ、とすら感じます(^^。
> 合ってますでしょうか？
> 結構，合ってる自信があるんですが(^^;
少なくとも、私の判断では、上出来の合致です。
でも、まあ、これだけバランスよくまとめられましたね。
どうも、私はこういうのが上手くないようです。
> （私の理解が合っているものと仮定しますと）この意見にはすっかり納得させられ
> てしまいました．「なるほどなるほど」って感じです．
よかった、よかった。
納得できるか、できないかは重要です。
でも、やはり実際にこれが正しいか、現場に臨んで、
判断することが大切だと思います。
> 16 パズルの抽象化
> http://member.nifty.ne.jp/masarl/article/nifty-logs.rsrc/16-puzzule.html
>
> 16パズルのプログラムを作ることを考えます．16 パズルの表面だけを捉えて，パネ
> ルクラスと盤クラスを作ってしまうと，これはアプリケーションに固有の上位レイ
> ヤーのオブジェクトになってしまいます．しかし，16パズルの本質は実は次のよう
> なものです．
>
> ・1から16番までの番号を順番にならべるソートの問題である．
> ・ただし，順番を変形するステップには制約条件がある．
>
> パネルがなくても，16パズルの本質は表せるわけです．こう捉えると，「16パズル
> というゲームそのものを再利用，拡張できる可能性が広がります．」
>
> つまり，対象の本質をより深く捉えることによって，オブジェクトの属するレイヤ
> ーを一段下げることが可能な場合が考えられます．こういう，「隠れた本質を捉え
> て再利用可能な方向へ持っていく」っていうのは重要かな，と思っていますし，ま
> た，できるようになりたいと思っています．
仕様モデルから実現モデルへの移行には、何らかの変換が
行われているはずです。ただ、ドメインによって、これが
余り気づかれなかったり、逆にその変換がキーであったりします。
事務処理や比較的単純な業務処理では、比較的シームレスに
行われているように感じます。しかし、制御系や複雑なシステムに
なると何らかのモデルに変換しないと制御しきれません。
石井さんの16パズルじゃないですが、私もそれこそパズルを
解くようなジョブをしたことがあります。やや特殊とかとは
思いますが、このような場合にはその変換が強く意識され、
そしてパターンが出現しやすいように思います。
＃フォースが強くなればなるほど、それまでとは異なる
＃パターンが姿を現す、といえるかも知れません。
> XP の，「今必要な部分だけ作ってしまえ」という考え方だと，こういう本質を捉え
> ようとする努力が否定されてしまうようで，少し悲しく思ったのです．これは私の
> 勘違いであったのかもしれませんが．
この部分はXPのスローガンに当たるところなので、それだけを
鵜呑みにするのはちょっと危ないかもしれませんね(^^。
やはりXPもソフトウェア開発の歴史の上に出てきたので、
ソフトウェアの文脈で判断しないとまずいかな、と思います。
まあ、なにはともあれ、これで、一応再利用性に関しては、
落ち着いたようで本当に良かったです。
＃私もほっとしました(^^。
寺田さん、お付き合い、ありがとうございました。
-- 長谷川(hasegawa@....jp)