自分自身を返すメリット

たまに見かけるインターフェイスですが....

public StringBuffer StringBuffer#append( String s );

というのが一番馴染みが深いかな？ これが StringBuffer#append() が StringBuffer を返す、というのは、要するに

append() したそのオブジェクト自身を返す

という動作です。ですからコードの最後は

return this;

で終わっているわけですね。Meyer 流の厳格に「funcion/procedure」を区別する立場だとイケナイことなのですが、

作用を受けた（副作用によって状態を変えた）自分自身を返すメソッド

なのですよね。でこういうメソッドを、意識的に作ることにどういうメリットがあるかな？というお話です。

StringBuffer#append() が自身を返す理由って、要するにこういう使い方が便利だからです。

StringBuffer sb = sb.append( a).append( "-").append(b).append("=");

勿論そうですよね....これがしたいからこそ、「自身を返すメソッド」であるわけです。同様に O/R マッピングツールの Criteria クラスもよくこういう設計をします。

 List cats = session.createCriteria(Cat.class)
     .createAlias("kittens", "kit")
     .add( Restrictions.like("kit.name", "Iz%") )
     .list();

これもホントは、Criteria が「StringBufferみたいなもの」ですから、org.hibernate.Criteria#add() などが、Criteria 自身を返して、

なんとなく SQL みたいに記述されたプログラム

の見かけを作り出すわけです....

ですから、ちょっとこういう概念はいかが？

自分自身を返すメソッドを作るのは、プログラムの「叙述性」を高めるメリットのためだ！

「叙述性」って言い方いいでしょ！ プログラムとしては別に特に機能的に変わるわけじゃないです。プログラムを

対象領域の処理について直感的に把握しやすくする目的で

言い換えれば「プログラマのために」こういう書き方を許そうとするのです...

ですから、Composite パターンで、入れ子の構造を作るメソッド add() も、やはり「自身を返すメソッド」であっていいです。なおかつ、

Composite add( Composite... args );

とうまく可変長引数を使ってやれば、こんな「叙述」ができます。

root.add( kodomo1.add( mago1.add( himago1,
                                  himago2 ),
                       mago2.add( himago3 ),
                       mago3 ),
          kodomo2.add( mago4.add( himago4 ),
                       mago5 ) );

どうです？「叙述性」を高めたプログラムとは、実際には「宣言的」でもあるようですよ。デザパタとして捉えて、何かカッコイイ名前をつけてあげたくなりました.....