read!さあ、いきなり、コードを見てみてください。Service相当のクラスが、そのLogicのメソッドを呼んでいると思ってください。いうメソッド見たことありませんか?読みやすいですか?さて、Logic側はこうなっています。memberList;}あなたが目撃者だったらさて、あなたはいま新しい画面の実装しています。このメソッドを呼びたいと思いますか?...いざ呼ぼうと思ったら、ちょっとだけ絞り込み条件が足りませんでした。しますか?読みづらさ大爆発jfluteは何度か見たことがあります。どんな検索をしているのか?それを確認するのに、ソースをあっちいったりこっちいったり。よるもので、引数の指定があったりなかったり、引数を指定する側でも分岐があったりすると、もう無理です。ちなみに勘違いしてはいけないのは、厳密には引数が多いからつらいのではなく、「引数でメソッドの処理を細かく操作しようとしている」という点です。それで引数が多いとなおさらと。(単にデータベースに登録する値とかであれば、引数クラスにまとめようくらいの話で済みます)デグレの温床Javaでは引数名指定のメソッド呼び出しができませんが、仮にできたとしても、50歩100歩です。読みづらさだけではなく、これだけ選択肢があるということは、だいぶ業務の違う画面同士で再利用されています。Logic内では複雑な分岐があり、修正には勇気が要ります。その勇気はありませんから、追加的な修正だけを行っていくと思います。理想的な修正をして綺麗に整えていくならまだしも、どんどんパッチ的な追加修正ばかり積み上げていくので、大抵、引数デザインが酷いことになりがちです。(そう、引数デザインが大事なパターンですが、引数デザインって難しいものです)引数のネーミングや、その抽象度もポイントです。引数から何をやっているのか想像が付きやすいかどうか?パッチ的な積み重ねをしていくと、なかなか、そういう引数にはならないものです。(不器用に)操作する姿、そこから...引数リモコンパターンと名付けました。誰が作るの?多くの場合、特定の誰か一人が作るわけではありません。最初に作った人も、引数リモコンパターンが好きなわけではないでしょう。最初は引数は三つくらいで、まあこの程度なら...と思ってサクッとやったくらいな。jfluteも、ちょっと引数にboolean渡して分岐とか、別にやらなくもないです。できるだけ内部的なものに限定したり、絶対に数が増えない状況であることを確認したり、できるだけ違う方法での表現を模索したり、特にこのパターンを名付けてからは気をつけてます笑。最初はそんなに引数は多くない。それくらいだったらまあ別にそんなつらくもない。別の人がそのメソッドを再利用するとします。使えそうなんだけど、ちょこっとだけ違う。そのとき、別に再利用せずに自分で0から実装してもいいのに、再利用目的意識の強いLogicクラスにそういうものがあると...「なんか、これを使わなきゃいけないのかな...」って思い始めます。確かに自分の要件と似てるから、使えるならその方が楽だし。いうことで、ちょこっと自分用の引数を追加して、自分の要件を満たします。誰もこれだけ巨大な引数リモコンパターンを作ろうとは思っていなかったのに、見事にできあがってしまいました。インクリメンタルな開発をする事業会社の方が発生しやすいかもですね。引数リモコンパターンはどんどん育てられていくのです。やめようと思ったときには時すでに遅し。「本当にこういう検索でいいのか?」を、確認すること自体が大変なので、一個一個、呼び出し側の要件を紐解いていっての修正、非常にコストがかかります。ルーズな再利用ならしない方がいいずばりこれです。へたな再利用ならしない方がマシ。できることはあまりないだろうと思っています。同じテーブルの検索にしたって、結局は画面によって、データ取得したいものが変わったり、並び順が変わったりするものです。画面によって微妙に変わってくると。A画面では関連テーブルのデータが20個必要、B画面では関連テーブルのデータが3個だけ必要、それ以外はだいたい検索条件は一緒。追加していって、引数リモコンパターン化していくのもつらいです。そこまで無理して再利用しなくていいのでは?というか、厳密な再利用にもなっていないのではないか?とも考えられます。それぞれ統一されているとは限らないので、何か条件を変えてもすんなりOKとはなかなかいかないでしょう。読みづらく挙動を厳密に確認しないと使えないメソッド、再利用する方が実装コストがかかってしまうかも。ConditionBeanを使っているならなおさら、ササッと書いてしまった方が速いでしょう。これは、「何を再利用しているのか?」が、ハッキリしていないことが原因です。紛れていて、はっきりしないから再利用の恩恵を受けられない。へたな再利用の典型だと考えます。...再利用しまくって、メンテするの怖いから、パフォーマンスチューニングもできないとか、そんなの最悪ですね。再利用したいものは他にもあるはず。再利用体力には限界がありますから、節約して、本当に再利用したいものに使って欲しい。where句の部品再利用でも、検索の中で再利用したいものもあります。それは絞り込み条件の一部分です。いう業務概念があったとして、それを表現する絞り込み条件が以下のようなものだとします。purchaseCB.query().setProductId_Equal(SPECIAL_PRODUCT_ID);});様々な画面の検索で、この三つの条件をベタベタ書くと、単に書くのが面倒だし間違える人もいるって話に加え、その業務概念の条件が変わったときに窮地に陥ります。いう絞り込み条件の具体的な実現方法は、一箇所にしたいものです。(サービス系のインクリメンタル開発ならなおさら)それならば、そこだけを再利用するような部品メソッドを作ってみんなで共有するようにしたいところです。表現するメソッドを定義。}}これを、それぞれの検索で再利用します。したいものが違っていたり、他の絞り込み条件があったりしても関係ありません。cb.query().addOrderBy_...}基点テーブルが変わっても構いません。検索まるごとの再利用よりも、部品再利用の方をオススメしています。検索まるごとの再利用をするならば、引数リモコンパターンにならないように、うまく設計する必要があるでしょう。そのためには、専門のマネジメントが必要でしょう。それなりに費用がかかるものだと思います。...検索まるごとの再利用ができるパターンは、なくはないけれども、一つのシステムにおいて、そんなに数は多くないと想定しているので、そのくらいの再利用は目をつぶってもいいかなと。それよりも、部品単位で小さい再利用を積み上げる方が、再利用の量は減るかもしれませんが、実際の現場にはフィットすると考えています。それがやりやすいのが特徴だと思っています。DBFluteのオフィシャルサイトにも、この話が書かれています。DBFluteルーズなDaoパターンだと発生しやすい!?これは、また別途ブログ書きますね。【追記】ルーズなDaoパターンなら見たくないこの引数リモコンパターンが発生した現場では、ほとんどにおいてDaoパターン、もしくは、それに等しいレイヤで検索をしているパターンでアーキテクチャデザインされていました。ConditionBeanこんなの書いてみました。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。