[seasar-javadoc:551] Re: org/seasar/framework/container/package.html
Koichi Kobayashi
koichik @ improvement.jp
2006年 9月 5日 (火) 02:00:45 JST
小林 (koichik) です.
Date: Sat, 02 Sep 2006 02:46:25 +0900
From: Hideaki Suzuki <suzuki @ uinet.or.jp>
To: seasar-javadoc @ ml.seasar.org
Subject: [seasar-javadoc:548] Re: org/seasar/framework/container/package.html
> > ついでに,ConstractorAssembler などへのリンクも assembler/〜.html に
> > しないと 404 になりそう.
> しまった!と思ったのですが、ConstractorAssembler は
> containerパッケージ に入ってました。 ホッ (^^;;;
ぐはぁっ,こちらも寝ぼけていたようです...
そうか,Assembler も Deployer もインタフェースは
container パッケージか...
失礼しました.
> 今のところcontainerパッケージに収まっているので、これについては、
> さらなるご意見を頂戴したいと思います。
はい,これでよいかと.
> ユーザの理解を助けることを目的としてクラス図を付けるのに、形だけの
> クラス図を付けても、意味ないですね…orz。
>
> それに、人間が書く場合は、同類のクラスを近くに配置したりとか、
> 要素の配置に意味を持たせることでUMLの仕様以上の付加情報を、
> 知らず知らずに含ませているものですからね…。
そうなんですよ.
それがない,自動生成しただけの図は正直役に立つのかなぁ,と.
> ■その他の変更点
> 「定義情報の取得方法(〜DefAware) 」の説明を、試しに「逆転の発想」
> で書き直してみました。
>
> 親要素から子要素の定義情報を取り出す方法は、親要素が2種類以上の
> 子要素をもつ場合※1があるため、子要素ごとにインターフェース※2として
> 定義されています。
>
> たぶんツッコミ所です。 (^^;;;
とっても微妙だ.(^^;
> 理由説明の「親要素が2種類以上の子要素をもつ場合※1があるため、」
> はいらないですかね…。
そうですねぇ...
インタフェースがたくさんある理由について書く必要があるかというと,
無くてもいいんじゃないかと思います.
〜定義がたくさんある理由も書いていないわけで.
それとは別に,〜DefAware が「定義情報の取得方法」なのは少し
違和感あるかも.
〜DefAware は確かに 〜Def の取得方法を提供しているけれども,
それは結果という気のせいが.
本質的には 〜Def を所有することができる,コンテナになることが
できる,という意味合いだと思うのですよね.
とはいえ,「コンテナ」という用語は S2 コンテナを表す以外は
あまり使いたくないので,そうするとなんだろ?
集約? 包含?
とりあえず集約でいいか.
<dt>定義情報の集約(〜DefAware)</dt>
<dd>
diconファイル上で<initMethod>要素の子要素として<arg>要素を書くように、定義情報は親子関係を持ちます。
定義情報の親は ArgDefAware や PropertyDefAware などのインタフェースを通じて、子要素である定義情報を追加したり取得する機能を提供します。
とかなんとか書いてみたテスト.
ちょっとイマイチですね...
--
<component name="koichik">
<property name="fullName">"Koichi Kobayashi"</property>
<property name="email">"koichik @ improvement.jp"</property>
<property name="blog">"http://d.hatena.ne.jp/koichik"</property>
</component>
seasar-javadoc メーリングリストの案内