Index: [Article Count Order] [Thread]

Date:  Thu, 24 May 2001 13:54:52 +0900
From:  Masashi Umezawa <umezawa@....jp>
Subject:  [XP-jp:01922] Re: ObjectDay2001  ,体験  XP 資料
To:  extremeprogramming-jp@....jp
Cc:  umezawa@....jp
Message-Id:  <3B0C941C37E.0920UMEZAWA@....2>
In-Reply-To:  <200105240346.MAA24491@....jp>
References:  <20010524093833B.hiranabe@....jp> <200105240346.MAA24491@....jp>
X-Mail-Count: 01922

こんにちは
梅澤です。

On Thu, 24 May 2001 12:46:03 +0900:
Toru TAKAHASHI <tooru6.takahashi@....jp> wrote:

> オブジェクト指向では、上記のデータはクラス内部に隠蔽されるので、
> データ構造の変更に対しては強いですよね。

強いとは言えると思いますが、データベース中心的な性質を持った
アプリを相手にする場合、やはりXPがしにくいということはあるか
と思います。

XPでは、クラスの構造なども、開発のライフサイクル内でインク
リメンタルにちょこちょこ変わっていくのを前提としています。
例:文字列の属性であった電話番号が、クラスとして外にでるなど。

こうした変化にDBのスキーマがついてこれるのかが問題になります。

既存のDBをいろんなアプリで参照していて、スキーマの変更を
しにくい場合や、新スキーマへデータのマイグレーションを大量に
行わなければならない場合など、embrace changeなどといって
ちょこちょこ変えがたいのも事実ではないでしょうか。

もっともDBの中にはスキーマの変更を自動的に、安全に行って
くれるものもあります。C3で使われた、GemStoneや、日本の
どこかの代理店で扱っているObjectivityは、クラスの構造が
変われば、 DBのスキーマ構造もそれに合わせて進化していく
Schema Evolution機能を持ったOODBMSです。

このような機能がサポートされていれば、Daily Schema Migration
という最近加わった新たなプラクティスも実施しやすくなりますね。

あとは、既存のDBのスキーマ構造を一切意識しないで済むような
Wrapperを作る方法もありますが、いずれにせよ、Wrapperの生成
などが自動化されていないとちょっと大変です。

> いわゆる抽象化ですよね。抽象化は設計の重要なファクターだと思います。
> 名前の付け方にはいつも悩んでしまいます。
> #「オブジェクトのよい名前の付け方」なんて本が出たら買ってしまうかも

Smalltalkをやってみましょう。名前に関するコミュニティの
うるささはピカ一ですよ。;-P

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --"!
[:masashi |^umezawa]
"The best way to predict the future is to invent it - Alan Kay"