[Seasar-user:20941] Re: [Doma] インターフェイスを継承したい

2011年 8月 2日 (火) 08:55:27 JST

中村(taedium)です。

確認ありがとうございました。
近日中に1.18.0としてリリース予定です。

> お世話になります。
> newtaです。
> 
> Daoの継承を行う実装をテスト実装してみました。
> 継承した形やオーバーライド、既存をそのまま呼び出したり、
> 追加メソッドの実行など
> こちらのやりたい形ですべて実行出来ました。
> 
> いつも対応ありがとうございます！
> 
> 
> 
> 2011年8月1日11:12 newta <[E-MAIL ADDRESS DELETED]>:
> > newtaです。
> >
> > いつもすばやい対応でありがとうございます。
> > 早速入れてやってみたいと思います。
> >
> >
> >
> > 2011年7月30日11:48 Toshihiro Nakamura <[E-MAIL ADDRESS DELETED]>:
> >> 中村(taedium)です。
> >>
> >>> EmpDaoで定義されたSQLをFulltimeEmpDaoで違うものを呼び出したいときだけ
> >>> FulltimeEmpDaoでオーバーライドしてメソッドを定義しなおすイメージではどうでしょうか？
> >>> あくまで@Daoアノテーションがついたインターフェイスで
> >>> そこに定義されているメソッドのみがSQLにマッピングされるイメージです。
> >>
> >> なるほど。
> >> SNAPSHOTで対応してみました。
> >>
> >> http://maven.seasar.org/maven2-snapshot/org/seasar/doma/doma/1.18.0-SNAPSHOT/doma-1.18.0-20110730.023024-1.jar
> >>
> >> @Daoが注釈されたインタフェースは、@Daoが注釈された
> >> インタフェースを1つだけextendsできるようにしました。
> >> 例えば、次のように書けるようになりました。
> >>
> >> @Dao public interface EmpDao { ... }
> >> @Dao public interface EmpCustomDao extends EmpDao { ... }
> >>
> >> 上のコードを書くと、aptで次のようなコードが出力されることになります。
> >>
> >> public class EmpDaoImpl
> >>  extends AbstractDao
> >>  implements EmpDao { ... }
> >>
> >> public class EmpCustomDaoImpl
> >>  exntends EmpDaoImpl
> >>  implements EmpCustomDao { ... }
> >>
> >> インターフェース上のオーバーライドは実装クラス上でのオーバーライドと
> >> なって出力されます。お試しください。
> >>
> >>> お世話になります。
> >>> newtaです。
> >>>
> >>> 中村さん返信ありがとうございます。
> >>>
> >>> ちょっとイメージが伝わってなかったのでもう少し説明させていただきます。
> >>>
> >>> >> インターフェイスの継承が出来るようにするのは難しいでしょうか？
> >>> > 例えば、こうしたいということですね？
> >>>
> >>> 片一方がメイン側で、こういう感じです。
> >>>
> >>> @Dao public interface EmpDao { ... }
> >>> @Dao public interface EmpCustomDao{ ... }
> >>>
> >>> ServiceやLogicもメイン側のEmpDaoのプロジェクト側で定義しています。
> >>>
> >>> Custom側でServiceやLogic側のフローが変わるようであれば、
> >>> ServiceやLogicをカスタマイズしてDIされるようにして、
> >>> DB定義の差分だけでいいならばEmpCustomDaoでSQLをオーバーライドして
> >>> 実行されるSQLを修正。
> >>> 追加で実行したいSQLがあれば、EmpCustomDaoで追加定義するイメージです。
> >>> 派生側ではEmpCustomDaoでDIして
> >>> EmpCustomDaoで追加定義されたメソッドも実行されます。
> >>>
> >>>
> >>> > 例えばですが、インタフェースの継承を認めるとすると、
> >>> > EmpDaoで定義されたメソッドはFulltimeEmpDaoのソースコード上に
> >>> > 存在しません（する必要がありません）が、一方で、そのメソッドに対応する
> >>> > SQLファイルは存在しているかもしれません。
> >>>
> >>> EmpDaoで定義されたSQLをFulltimeEmpDaoで違うものを呼び出したいときだけ
> >>> FulltimeEmpDaoでオーバーライドしてメソッドを定義しなおすイメージではどうでしょうか？
> >>> あくまで@Daoアノテーションがついたインターフェイスで
> >>> そこに定義されているメソッドのみがSQLにマッピングされるイメージです。
> >>>
> >>>
> >>> > 代替案ですが、Adapterを作ってDaoを呼び分けるというのはどうでしょうか？
> >>>
> >>> 代替案だとやはりAdapter形式にですよね。。
> >>> そうすると今のイメージではすでにメイン側のDaoがあるので
> >>> メイン側の上につく@Daoの無い通常のインターフェイスのDaoと
> >>> Adapterクラスが必要になりますよね。。
> >>>
> >>> メイン側のDaoにも手が入ってしまうので、
> >>> ちょっと対応を考えてみます。
> >>>
> >>>
> >>> 今の状態としては
> >>> メイン側はすでに多数実装済みで、手を入れることも出来るのですが、
> >>> 全てに対応を入れるのはちょっと大変な量。頑張れば出来なくはない感じ。
> >>>
> >>> 派生側の実装設計をしているところです。
> >>>
> >>>
> >>> もうすこし他に案などありましたらお願いします。
> >>>
> >>> 自分もDomaToolなどを見ながら
> >>> もうちょっと考えて見ます。
> >>>
> >>> 以上、よろしくお願いします。
> >>>
> >>>
> >>> 2011年7月29日6:13 Toshihiro Nakamura <[E-MAIL ADDRESS DELETED]>:
> >>> > 中村(taedium)です。
> >>> >
> >>> >> インターフェイスの継承が出来るようにするのは難しいでしょうか？
> >>> >
> >>> > 例えば、こうしたいということですね？
> >>> >
> >>> > public interface EmpDao { ... }
> >>> > @Dao public interface FulltimeEmpDao extends EmpDao { ... }
> >>> > @Dao public interface ParttimeEmpDao extends EmpDao { ... }
> >>> >
> >>> > 技術的にはできるのですが、
> >>> > インタフェースの継承を制限しているのは
> >>> > ツール（Eclipseプラグインやapt）との相性を考えたからです。
> >>> >
> >>> > 例えばですが、インタフェースの継承を認めるとすると、
> >>> > EmpDaoで定義されたメソッドはFulltimeEmpDaoのソースコード上に
> >>> > 存在しません（する必要がありません）が、一方で、そのメソッドに対応する
> >>> > SQLファイルは存在しているかもしれません。
> >>> > その場合、Doma ToolsでDaoメソッドからSQLファイルへジャンプできません。
> >>> > また、Daoメソッドが存在しないことで、メソッド部分に出力すべき
> >>> > エラーのマーク（aptで出力）も直感的ではなくなってしまいます。
> >>> >
> >>> > 代替案ですが、Adapterを作ってDaoを呼び分けるというのはどうでしょうか？
> >>> > 例えば、上の例を元にすると次のようなクラス階層が考えられます。
> >>> >
> >>> > public interface EmpDao { ... }
> >>> > public class FulltimeEmpDaoAdapter implements EmpDao { ... }
> >>> > public class ParttimeEmpDaoAdapter implements EmpDao { ... }
> >>> > @Dao public interface FulltimeEmpDao { ... }
> >>> > @Dao public interface ParttimeEmpDao { ... }
> >>> >
> >>> > コードは増えてしまいますが、Adapterのコードは
> >>> > Daoに委譲するだけのシンプルなものになるはずです。
> >>> > 数が多いならコード生成で作ってしまうのがいいかもしれないですね。
> >>> >
> >>> >> お世話になります。
> >>> >> newtaです。
> >>> >>
> >>> >> 表題の通りの要望なのですが、
> >>> >> 非常に似たテーブルがあり、
> >>> >> Daoの生成以外では
> >>> >> Daoを使うフローも同じ、返すDtoも同じ
> >>> >> sqlのみ微妙に違うと言うことがしたいです。
> >>> >>
> >>> >> 今、利用しようとしている構成では2つのアプリがあり、
> >>> >> 通常アプリとそこから分岐する派生アプリで
> >>> >> フローは共通のまま、Daoのみインスタンス生成の部分のみコントロールして
> >>> >> 一部のメソッドのみオーバーライドして微妙変更されたものに差し替えたいのです。
> >>> >> （インスタンス生成部分に関してはDIでコントロールしています)
> >>> >> なので、ちょっと数が多くなるかもしれないので出来ればフロー部分のクラスを作らず、
> >>> >> Daoの生成をDI時にコントロールしてしまいたいと思っています。
> >>> >>
> >>> >> ソース生成のときに考慮しなければならないことも結構増えてしまうと思いますが、
> >>> >> インターフェイスの継承が出来るようにするのは難しいでしょうか？
> >>> >>
> >>> >> 以上、よろしくお願いします。
> >>> >> _______________________________________________
> >>> >> Seasar-user mailing list
> >>> >> [E-MAIL ADDRESS DELETED]
> >>> >> https://ml.seasar.org/mailman/listinfo/seasar-user
> >>> >
> >>> > --
> >>> > Toshihiro Nakamura <[E-MAIL ADDRESS DELETED]>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Seasar-user mailing list
> >>> > [E-MAIL ADDRESS DELETED]
> >>> > https://ml.seasar.org/mailman/listinfo/seasar-user
> >>> >
> >>> _______________________________________________
> >>> Seasar-user mailing list
> >>> [E-MAIL ADDRESS DELETED]
> >>> https://ml.seasar.org/mailman/listinfo/seasar-user
> >>
> >> --
> >> Toshihiro Nakamura <[E-MAIL ADDRESS DELETED]>
> >>
> >>
> >> _______________________________________________
> >> Seasar-user mailing list
> >> [E-MAIL ADDRESS DELETED]
> >> https://ml.seasar.org/mailman/listinfo/seasar-user
> >>
> >
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user

-- 
Toshihiro Nakamura <[E-MAIL ADDRESS DELETED]>