Index: [Article Count Order] [Thread]

Date:  Sat, 23 Sep 2000 21:43:12 +0900
From:  "hasegawa" <hasegawa@....jp>
Subject:  [XP-jp:00925] Config等について
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <011201c0255b$a9d58bd0$640aa8c0@....jp>
References:  <97BA340C0480D411BDA800062939A1890607AF@....jp> <39CC53F6.84FCED1D@....jp>
Posted:  Sat, 23 Sep 2000 21:41:54 +0900
X-Mail-Count: 00925

はじめまして、テクノポートの長谷川と申します。

このMLはかなり昔(No0025)から拝見させてもらっていました。
興味はあったのですが、ついROMになってしまいました。
#本当は、Alex.が話題に上ったときにポストしたいと思ったのですが、
#時間が取れずに、機を逃してしまいました(^^;。

ところで、最近、Configファイル等について議論されていて、
興味があったので色々読み返しましたが、どうもいまいち、
何が問題なのかはっきりしませんでした。
で、的を外すのは覚悟の上で、私が以前から考えている
ことについて述べてみようかと思いました。
#何が問題なのかをはっきりさせる一助にでもなれば幸いです。


以前、オプションカードというパターンを考えたことがあります。
今ではプリセットやプリファレンスにまで広がりつつあります。
プリセットというのはConfigファイルのように、その情報なしには
作動できない設定を相手にし、プリファレンスはデフォルト値のような
その人の好みの設定を相手にします。
#memberlistなどは少し毛色が違うかと思っています。

で、これらが一体どういう問題を解決するのかというと、
部品の可動性(様々な環境可で動作する、動作をカスタマイズするなど)を
高めることと、部品が特定のアプリケーションを超えることだと思っています。
特に私は後者が重要と思っています。
つまり、部品が直接外部情報にアクセスすると、
別のアプリケーションでは使えなくなるかもしれない、
しかしそれらの設定なしには動作できないという状況下で
取られたひとつの解決法だと思います。

これに関しては、今の所、契約としてアプリケーションが
部品に必要な情報を提供するしかないと私は考えています。
そして、その契約がXXカードといったものです。
#と言っても、今はカートリッジになっていますが(^^;。
契約は仕方がないとしても、単に押し付けだけの規則は嫌いなので、
何とかその契約を遂行させる援助が必要だと思い、最も単純な
tag-value方式の汎用クラスを用意してやるのがいいかと思っています。
アプリケーション側は、ファイルからでもレジストリからでも
はたまた、DBからでも読み込み、それに入れ、部品側はそこから読み込めば
余り大きな負担にならずに機構を構築できると考えています。

で、何がいいたいかと言いますと、アプリケーションと部品の関係、
そして再利用性ということなしに、こういったことを考えても
意味がないんじゃないかということです。
現在私が加わっているプロジェクトでも、コンフィグファイルから
読み込んだデータをグローバルデータに突っ込むだけのものや、
ちゃんとプロセス間通信やDBアクセス用のモジュールに伝達する
仕組みを組み込んだものなど色々とあります。

後者は、あくまで、部品、モジュール、ユニットなどと呼ばれるものの
再利用性を考慮して初めてそういった形になったものです。
そうでなければ、どんなやり方も五十歩百歩に過ぎないと感じています。
今の所、私には皆さんのやられているものについて、全体像がよく見えず、
何が部品なのかも良くわかりません。
#マップらしきものがないようですね。

ただ、もし部品の再利用性が余り意味のないことなら、
ファイルがひとつでもいくつになろうと、大した問題ではないように思います。
逆に、部品の再利用性を考慮されるなら、部品にとって必要な情報を提供する
ということさえ決めれば、アプリケーションレベルでのデータの読み込みは
どのようなファイルでも余り大した問題にならないと思っています。
#部品が特定ファイルを要求するのは部品の仕様で、
#アプリケーションはパスを提供することぐらいしかできないかと。

実際、時間が経てば、操作のしやすさにより変更されるだろうし、
ローミングサービスを提供するとなるとDBに入れるかも知れません。
#こういったことが言えるのはXPのよい面と思っています(^^;。
しかし、そういったことになっても、部品を変更することはないでしょう。
#機能追加などはまた別の次元、と考えてですが。

#こういったことを言うことに対して、私自身は少し躊躇しました。
#これはXPのやり方ではないんじゃないかと思ったからです。
#XPを誤解している点もあるかとは思いますが。

あ、それとついでなので、「テストのためだけのメソッド」に
ついて述べさせてください。
#今度、いつポストできるかわかりませんので(^^;

私はテストだけのメソッドは含めない方がいいと思っています。
そして、ホソカワさんが提示された「ヘルパークラス」がよい方法と思います。
少し状況は違いますが、同じような問題から同じような解法に辿りついた
経験があります。それは、「クラスのメソッド数を最小にする」という問題で、
解法は、核となるメソッドを使って処理可能なメソッドを別のクラスとして
用意するとものでした。こちらは、少々現実的に難しいものがありますが、
テストメソッドに関しては、適していると思います。


もっぱらROMの私ですが、楽しませてもらっています。
ファウラさんのpaperも読ませてもらいましたし、
何よりも触発されることが多いです。
かげながら、応援しています。頑張ってください。
#こういうスタンスも許してください(^^;。
----------------------------------------------
## テクノポート:長谷川(hasegawa@....jp) ##
----------------------------------------------