*目次 [#nae59937] #contents *流れるようなinterface(fluent interface)[#r808f167] 流れるようなInterfaceって大まかにいうと下記の主張をしている。 -外部に公開して利用してもらう手続き(interface/API)は、たとえ時間をかけてでも以下の条件を満たすよう設計すべきである。 --手続きの名称が適切で、それを利用したコードの可読性が高いこと --利用者への要求が可能な限り少ないこと -関数言語的なつくりを意識すること --演算結果を再度取り込んで処理を行うようなことはしない。用意したインタフェースの先で処理をさせる。 静的な型付き言語だと、流れるようなインタフェースをライブラリが用意してくれていると、バグの発生が少なくなる。なぜかというと普通よく見かけるプログラミングでは戻り値に変数String resultに値が帰ってくるだけだが、そのresultの使い方の選択肢は無限にあり、その選択肢にはバグの選択肢がたくさんふくまれているからなのだ。 ところが、流れるインタフェースでは正解となるインタフェースしか用意されていない。 結果を処理するクラスとメソッドを探す手間が不要で、間違いがない。だからバグが少ないのだ。 **自分の意見 [#p749bb10] 自分は昔から、流れるようなインタフェースでプログラムをつくってきた。流れるようなインタフェースを作る時の留意する点は下記のとおりである。 -カリー化の考えをマスターすること。 --簡単に言うとメソッドの引数は極力ひとつが望ましい。 --クラスをカリー化で使う変数の概念ごとに用意する -標準的なクラスはエラーを含むすべての選択肢に対応したインタフェースを持つ傾向があるため、これらのクラスをラップしないと流れるインタフェースが手に入らないケースがほとんどである。 JavaAssistは動的にクラスを作り、しかもバイトコードなので、実際のIDEを使ったコーディング時に、流れるインタフェースを使う用途には、向いていない。 *提案目的 [#h33e44c7] 流れるインタフェースは、設計思想ごとにグループを持つと思われるが、 それだと、ほかの人のソースコードを転用する際に設計概念をあわせなくてはならないので、面倒だ。だから下記の提案をする。 問題は誰に向けての提案なのかということなのだが。気にしないでおこう。 **提案内容 [#k01e9a2c] -すべてのクラスの流れるインタフェース版はクラス名の後にFluentのFluをつける。 -内部的に元になるクラスのインスタンスを1つ持ち、getCore()メソッドで取得できることとする。 -上流のクラスがあれば、アノテーションで上流のクラスを指定する。 -すべての流れるインタフェース用のソースコードは編集可能でなくてはならない。 -antで上流のクラスのソースコードにtoXXXメソッドを自動的に追加するぐらいの配慮が必要 **例はJMockのソースコード [#g798913e] mock.expects(once()).method("m").with( or(stringContains("hello"), stringContains("howdy")) ); **Martin Fowler's Bliki [#leae7edb] http://martinfowler.com/bliki/ ***日本語訳 [#t269ef41] http://capsctrl.que.jp/kdmsnr/wiki/bliki/