Junichi Kato
j5ik2****@gmail*****
2008年 6月 9日 (月) 02:02:03 JST
MIYAMOTO Daisuke さんは書きました: > 都元です。 > > えっと、加藤さん案（compositeパターン）を試してみようと思ったのですが、 > 軽く壁にぶつかったのでご報告。 > > PKでもUNIQUEでもCHECKでも、制約には名前がつくものですよね。 > （大抵はRDBMS側で制約名を自動生成していますので、意識しない所ですが。） > その為、Constraintインターフェイスにはnameのaccessorを記述してあります。 > あらー，そうですよね．名前付くねー．うむー． > ComplexConstraintModelに対してgetNameが来たら、どの名前を返せば > いいのでしょうか、というよりも、それぞれの制約に対して別々にgetNameして、 > その名前を処理したいと思います、client側は。 > > というところに迷ったのですがーー。どうしよ。 > そういう意味では，ComplexConstraintModelをひとつの制約として見立てるには無理がありそうですねｗ ただの，ConstraintContainerModelとして一つの制約でもない複数の制約を管理できるただのコンテナクラスにしてしまったほうがよいのかな． ConstraintContainerModelから，順番に制約情報を取り出して処理するか？ どうでしょうか？みなさま > > 2008/06/07 11:26 MIYAMOTO Daisuke <daisuke_m****@yahoo*****>: > >> 都元です。 >> >> ご意見ありがとうございますー。 >> なるほど、Compositeか。以下のように考える訳ですねー。 >> >> Component → Constraint(抽象的制約) >> Composite → ComplexConstraint (複合制約 = コンテナ) >> Leaf → NotNullConstraint, UniqueConstraint... (具体的制約) >> >> Compositeってツリー構造を表現するのに最適というステレオタイプしか持ってなかったもんでｗ >> この方式で作ると、コンテナの中にコンテナ、という多重入れ子のオブジェクト状態が作れて >> しまいますよね？ 「カラム制約」という要件上、多重入れ子は不要なんです。 >> まぁ、使わなければいいんですが、タイプセーフ的じゃないなぁ、というのが懸念点。 >> >> あとは、インターフェイスをもっと切って「コンテナはコンテナを保持できない」ように作る事も >> 可能ですが、いたずらに型数を増やしてしまう気もしますーー。 >> >> というわけで、現在の所 shin1さん案でフラットにしてありまっす。 >> >> 2008/06/06 22:10 Junichi Kato <j5ik2****@gmail*****>: >> >>> かとうです。 >>> >>> 08/06/06 に MIYAMOTO Daisuke <daisuke_m****@yahoo*****> さんは書きました: >>> >>>> 都元でっす。 >>>> >>>> >>>> というフィールドになると思います。 >>>> RDBMSには NOT NULL, UNIQUE, PRIMARY KEY, CHECK という4種の制約がありますが、 >>>> （他にあったっけｗ） これらをConstraint型でどのようにあらわすか、に悩んでます。 >>>> >>>> 「PK = UNIQUE + NOT_NULL + α」の制約と考えて、 >>>> >>>> interface Constraint >>>> class NotNullConstrait implements Constraint >>>> class UniqueConstraint implements Constraint >>>> class PrimaryKeyConstrait extends NotNullConstrait, UniqueConstraint >>>> class CheckConstraint implements Constraint >>>> >>>> ...って多重継承してるじゃんオイｗ かといって、NotNullとUniqueはインスタンスが >>>> 必要なのでinterfaceにする訳にはいかない。 >>>> あれ、NULL入れられるPKってあったっけ？ 入れられるとしたら >>>> >>>> interface Constraint >>>> class NotNullConstrait implements Constraint >>>> class UniqueConstraint implements Constraint >>>> class PrimaryKeyConstrait extends UniqueConstraint >>>> class CheckConstraint implements Constraint >>>> >>>> かなぁ。っていうかもう、 >>>> >>>> interface Constraint >>>> class NotNullConstrait implements Constraint >>>> class UniqueConstraint implements Constraint >>>> class PrimaryKeyConstrait implements Constraint >>>> class CheckConstraint implements Constraint >>>> >>>> と、フラットにしてしまうか？ >>>> っていうかそもそも Constraint は interface か？ など。 >>>> >>> >>> 自分だったら、コンポジットパターンを使うよ。 >>> 複数の制約を持つ必要があるなら、Constraint から派生したコンテナクラスにConstraint 派生した各制約クラスを追加します。 >>> S2のAOPのカスタマイザーはこのような仕組みになっています。 >>> コンテナもひとつの制約なので、透過的に扱えるようになるはずです。なので、コンテナタイプの制約と、フラットな構造の各制約クラスがあればクラス構造も複雑にならずによいです。 >>> >>> 以上、よろしこ。 >>> >>> >>> >>> >>>> ご意見募集。 >>>> >>>> # 間違って seasar-dev に誤爆しそうになった（汗 >>>> -- >>>> MIYAMOTO Daisuke >>>> skype: cuervo1800 >>>> >>>> _______________________________________________ >>>> Jiemamy-dev mailing list >>>> Jiema****@lists***** >>>> http://lists.sourceforge.jp/mailman/listinfo/jiemamy-dev >>>> >>> _______________________________________________ >>> Jiemamy-dev mailing list >>> Jiema****@lists***** >>> http://lists.sourceforge.jp/mailman/listinfo/jiemamy-dev >>> >>> >>> >> >> -- >> MIYAMOTO Daisuke >> skype: cuervo1800 >> >> > > > >
