Index: [Article Count Order] [Thread]

Date:  Mon, 05 Mar 2001 05:41:49 +0900
From:  yterada@....jp (Y.Terada)
Subject:  [XP-jp:01682] Re: XP で再利用できますか?
To:  extremeprogramming-jp@....jp
Message-Id:  <20010304201950118.AAA228@....jp@ginza>
In-Reply-To:  <006901c0a4c7$2d151f20$640aa8c0@....jp>
References:  <006901c0a4c7$2d151f20$640aa8c0@....jp>
X-Mail-Count: 01682

寺田@東工大 です.
長谷川さん,こんにちは.
太田さん,はじめまして.

すごく変な時間にメールかいてます.
卒業に際し,大学の PC から必要なファイルを整理してバックアップしていたので
すが,思いのほか時間がかかってしまいました.


> やっぱり、パターン=デザインパターン、そして
> パターンランゲージって何?という状況が少しつらいです(^^。

申し訳ありません.そのとおりです.
「パターン」は意味が分かってる(つもり)のですが,「パターン・ランゲージ」
という言葉は聞いたことがあるだけで意味が分かっていません.
勉強不足で申し訳ないです.

ですが,ようやく,長谷川さんのおっしゃっていることが分かり始めたような気が
しています.何となく,ですが.私の理解を書いてみますので,長谷川さんのご意
見を誤解している部分がありましたらご指摘ください.

--- 以下,私の理解 ---

(パターン等の)再利用,というと,本質を見ることなく型にはめていくだけで素
晴らしい製品ができる,と言っているように感じられるが,それは正しくない. 

既存の部品やパターンをただ機械的に並べていくだけでは,いつまでたっても真に
素晴らしい製品には辿り着けない.既存部品を利用したり,既存のパターンを参考
にしたりすることはあっても,それだけでは成功しない.様々なシステムの仕様は
すべて異なるものでありどれ一つとして同じものは存在しないのだから,すべての
システムに適用できる画一的な部品やパターンは存在しない.

良いシステムを作るためには,そのシステムに固有の「本質」を見抜き,システム
に合わせて柔軟にパターンを適合させていく必要がある.このように,システムに
合わせてパターンを適合させるような設計をするためには,パターンを名前から想
起される即物的なイメージだけで捉えていてはいけない.個々のパターンの意味や
本質をしっかりと理解しておく必要がある.

従来のオブジェクト指向方法論では,パターンの本質的理解を促進しない.あるい
は,機械的な適用を促している.つまり,将来の変更や拡張を完全に予測した柔軟
性の高い設計を行い,それ以降はフレームワークに機械的に従うだけで良いシステ
ムが構築できることを目指している.そのため,設計者は常に,自分の設計が十分
な柔軟性を持っているものなのか不安にさらされることになる.

XP はこのような状況を打開するものである.XP は YAGNI の原則などにより,将来
の変更を予測した柔軟性を持たせることに対して否定的である.パターンは参考に
するが,部品やパターンの画一的,機械的な再利用を否定する.これは,逆にいえ
ば,システムごとに固有の本質を見抜き,そのシステムに最も自然な設計を行うこ
とを促進している.

すなわち,XP はシステムから機械的な再利用を排除し,ごく自然に「本質」へと辿
り着く道しるべとなっている.「XP で再利用できますか?」という問いに対しては,
「機械的で間違った再利用を排除し,真に有用な本質の再利用を促進することがで
きる」というのが答えとなる.XP における再利用とは,「部品だから」「パターン
だから」という形式ばったものではなく,もっと自然に導入されるものである.

--- 以上,私の理解 ---

合ってますでしょうか?
結構,合ってる自信があるんですが(^^;

(私の理解が合っているものと仮定しますと)この意見にはすっかり納得させられ
てしまいました.「なるほどなるほど」って感じです.


太田さん:
> >  一方、寺田さんの仰る部品の再利用の有効性についても私は理解できます。
> > 一利用者の観点からもJava APIのような洗練されたフレームワークを用いる
> > と、低レベルの実装に惑わされることなくスムーズに設計、プログラミングを
> > 行うことが出来ます。
> >  ただ、このレベルで言う部品は実務のレベルでは非常に下の部分であると思
> > います(私も学生なのでたいしたことは言えませんが)。寺田さんの仰った
> > VectorやListという下位レベルのオブジェクトはビジネスモデルを作り上げる
> > 段階ではどうでも良いとは言いませんが、それほど気にはとめないものです。
> > 長谷川さんが仰られたのはこのビジネスモデルのレベルにおいて部品としての
> > 再利用はあきらめたほうが良いということではないでしょうか。このレベルの
> > オブジェクトを再利用部品にすることは建築で言えば、既成のシステムキッチ
> > ン、システムバスのようなものであり、例え実現できても利用者の要望を満た
> > すものからは程遠いものになる可能性があります。

そうですね.長谷川さんと私は対象としている「再利用部品」のレイヤーが食い違
っていたような気がします.私は比較的下位のレイヤーを考えていたのに対し,長
谷川さんはもっと上位のレイヤーを考えていたようです.

太田さんのご意見を逆に捉えると,下位レイヤーのオブジェクトなら十分に再利用
の可能性があると言うことになりますよね.私がなんとなく考えているのは,上位
のレイヤーに属する(と思われていた)オブジェクトが,下位レイヤーに落とせる
場合があるんじゃないか,ということです.

実は先日,石井勝さんの「まさーるのページ」を読んでいて,以下の記事にぶつか
りました.この記事が,私がぼんやりとイメージしていた「理想の再利用」とドン
ピシャであるように感じたので,ちょっと紹介させて頂きます.
(石井さん,素晴らしい記事を本当にありがとうございます.)

16 パズルの抽象化
http://member.nifty.ne.jp/masarl/article/nifty-logs.rsrc/16-puzzule.html

16パズルのプログラムを作ることを考えます.16 パズルの表面だけを捉えて,パネ
ルクラスと盤クラスを作ってしまうと,これはアプリケーションに固有の上位レイ
ヤーのオブジェクトになってしまいます.しかし,16パズルの本質は実は次のよう
なものです.

・1から16番までの番号を順番にならべるソートの問題である.
・ただし,順番を変形するステップには制約条件がある.

パネルがなくても,16パズルの本質は表せるわけです.こう捉えると,「16パズル
というゲームそのものを再利用,拡張できる可能性が広がります.」

つまり,対象の本質をより深く捉えることによって,オブジェクトの属するレイヤ
ーを一段下げることが可能な場合が考えられます.こういう,「隠れた本質を捉え
て再利用可能な方向へ持っていく」っていうのは重要かな,と思っていますし,ま
た,できるようになりたいと思っています.
XP の,「今必要な部分だけ作ってしまえ」という考え方だと,こういう本質を捉え
ようとする努力が否定されてしまうようで,少し悲しく思ったのです.これは私の
勘違いであったのかもしれませんが.

  _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

      Yuichiro TERADA

      Tokyo Institute of Technology,
      Kobayashi/Todoroki Lab.
      + yterada@....jp
      + http://ginza.mes.titech.ac.jp/~yterada

  _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/