流れるようなインタフェース のバックアップ(No.1)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- 流れるようなインタフェース へ行く。
- 1 (2010-11-06 (土) 22:49:01)
- 2 (2010-11-06 (土) 23:57:49)
- 3 (2010-11-07 (日) 09:31:05)
流れるようなinterface(fluent interface) †
流れるようなInterfaceって大まかにいうと下記の主張をしている。
- 外部に公開して利用してもらう手続き(interface/API)は、たとえ時間をかけてでも以下の条件を満たすよう設計すべきである。
- 手続きの名称が適切で、それを利用したコードの可読性が高いこと
- 利用者への要求が可能な限り少ないこと
- 関数言語的なつくりを意識すること
- 演算結果を再度取り込んで処理を行うようなことはしない。用意したインタフェースの先で処理をさせる。
静的な型付き言語だと、流れるようなインタフェースをライブラリが用意してくれていると、バグの発生が少なくなる。なぜかというと普通よく見かけるプログラミングでは戻り値に変数String resultに値が帰ってくるだけだが、そのresultの使い方の選択肢は無限にあり、その選択肢にはバグの選択肢がたくさんふくまれているからなのだ。
ところが、流れるインタフェースでは正解となるインタフェースしか用意されていない。 結果を処理するクラスとメソッドを探す手間が不要で、間違いがない。だからバグが少ないのだ。
自分の意見 †
自分は昔から、流れるようなインタフェースでプログラムをつくってきた。流れるようなインタフェースを作る時の留意する点は下記のとおりである。
- カリー化の考えをマスターすること。
- 簡単に言うとメソッドの引数は極力ひとつが望ましい。
- クラスをカリー化で使う変数の概念ごとに用意する
- 標準的なクラスはエラーを含むすべての選択肢に対応したインタフェースを持つ傾向があるため、これらのクラスをラップしないと流れるインタフェースが手に入らないケースがほとんどである。
JavaAssist?は動的にクラスを作り、しかもバイトコードなので、実際のIDEを使ったコーディング時に、流れるインタフェースを使う用途には、向いていない。
例はJMockのソースコード †
mock.expects(once()).method("m").with( or(stringContains("hello"),
stringContains("howdy")) );
Martin Fowler's Bliki †
http://martinfowler.com/bliki/
日本語訳 †
