赤坂です。
ごうぎさん、情報ありがとうございます。
Shigeru GOUGI <ANC04864@....com> san wrote:
> このあたりとてもわかります。個人的にはコンポーネント指向へと移っていくよ
> うな感触があります。その際、コンポーネント基盤かそれとは別の枠組みでコンポ
> ーネントをテストできる環境があるとよいのですが。
なるほど、コンポーネントという手もありそうですね。
> あと、アーキテクチャやコンポーネントの設計については（実際にまだ使ったこ
> とがないのですが）「デザイン構造マトリクス」というのが良いツールになるよう
> な気がしています。http://www.dsmweb.org/
> このツールを使うとコンポーネント分割する際その分割されたコンポーネントや
> コンポーネントのインターフェースが自然かシンプルかそういったものを同時にみ
> れそうに感じています。（禅庭が持つようなシンプルさや自然さはみれないですが。）
>
> ＃ デザイン構造マトリクスを使ったソフトウェア開発での事例などあればしりたい
> ＃ です。
> ＃ ラップトップコンピュータの設計について、簡単ですが洗練していく様子が、
> ＃「モジュール化」http://www.amazon.co.jp/exec/obidos/ASIN/4492393706/of-22
> ＃ にのっています。
情報ありがとうございます。
（英語なのでのんびりとですが(^^;;）見てみます。
> Hidehiko AKASAKA wrote:
> > クラスレベルでこれを実現するのは、今の私のレベルでは難しいです。
> > 現状では、パッケージ内部については妥協（変更の伝播を容認）し、外部のパッ
> > ケージに変更の伝播がなければOKとしています。
> > # もちろん、単体テストを考えると、パッケージ内部のクラス同士も関係は疎な
> > # 方が良いのですが、うまく実現できていないので、当然整理もできません。
個人的には、なんとか「アスペクト指向」に繋げたいと思っていました。
これら変更の影響（絡み合い）は、視点(あるいは様相、アスペクト)を変えるこ
とで軽減できるのではないかと。
# 単純に私の興味がそこに向いているから、というのが本当の理由です(^^;;
ただ、無理解のため、どんなケースで適用できて、テストがどう楽になるのか、
さっぱり分かりません。
#どのように話を持っていくと、そこへ繋がるのかすら分かりません(^^;;
Aspect指向な人のご意見は伺えないですヨねぇ...
--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka.h@....com