[seasar-javadoc:548] Re: org/seasar/framework/container/package.html

[Hideaki Suzuki]

鈴木(belltree)です。

小林さんコメントありがとうございます。mOm

■コメントに関して

> 前半の説明の最後ですが，「コンポーネントの構築方法（〜Assembler）」は
> パッケージが違うので，assembler パッケージだということを書いた方が
> いいかも．
よくよく見ると、InitMethodAssemblerというインターフェースは
ありませんでした… (^^;;;; 編集当時、睡眠直前状態だったので、
よくチェックしていませんでした…と言い訳してみたり… orz

で、MethodAssembler が initMethod/destroyMethod 共通の
assemblerなので、これに置き換えて補足を付けました。

> ついでに，ConstractorAssembler などへのリンクも assembler/〜.html に
> しないと 404 になりそう．
しまった！と思ったのですが、ConstractorAssembler は 
containerパッケージ に入ってました。 ホッ (^^;;;

> assembler パッケージも含めて説明するなら，deployer も含めたいと
> 思ったのは私だけ？ (^^;
多くの人が初めに見ることが予想されるパッケージなので、
良い羅針盤とするためには、サブパッケージの概要と、その関連を簡潔に
書くことが効果的かなぁ〜とも思えてきました。
ちょっとDRYじゃなくなりますが…
でも、DRY vs ユーザーニーズ を考えると、やっぱり後者に軍配?

今のところcontainerパッケージに収まっているので、これについては、
さらなるご意見を頂戴したいと思います。

> > これにクラス図を追加したいなぁ〜と思っています。
> > きっと UML2.0言語を話す種族の人々には、有益かと思うので…。
> > ただし、ソースの変更に伴って、クラス図を書き換えなければならない
> > のでは、DRYぢゃないので、個人的には自動生成がいいなぁなんて…
> 
> 個人的には自動生成反対．
> 配置とか無意味にされても見づらいだけだし，それだったら
> 欲しい人が自分で生成してもいいんじゃないかと．
> こちらで用意するなら，単なる自動生成よりも価値のあるものに
> したいなぁと思います．
> 最初にツールに自動生成させて，それを手直しとかならいいですけど．
確かに…orz。
ユーザの理解を助けることを目的としてクラス図を付けるのに、形だけの
クラス図を付けても、意味ないですね…orz。

それに、人間が書く場合は、同類のクラスを近くに配置したりとか、
要素の配置に意味を持たせることでUMLの仕様以上の付加情報を、
知らず知らずに含ませているものですからね…。

理解を助ける意味からすると、ここは ArtなMindMap の出番かぁ? (→画伯?)
(嘘です… ^^;;;)

というわけで、自動生成＆手直しに +1。

■その他の変更点
「定義情報の取得方法（〜DefAware） 」の説明を、試しに「逆転の発想」
で書き直してみました。

  親要素から子要素の定義情報を取り出す方法は、親要素が2種類以上の
  子要素をもつ場合※1があるため、子要素ごとにインターフェース※2として
  定義されています。 

たぶんツッコミ所です。 (^^;;;
理由説明の「親要素が2種類以上の子要素をもつ場合※1があるため、」
はいらないですかね…。

p.s. 
いや〜、junduさんの説明文、やっぱいいですね勉強になります。多多多謝！

/** 
 * @auther Hideaki Suzuki
 * @contact suzuki at uinet.or.jp
 */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.seasar.org/archives/seasar-javadoc/attachments/20060902/0eaf4ac0/attachment.html