ジェネリクス

ジェネリックなクラスの階層を遡って適用された具象型を得る

凪瀬 — Wed, 29 Oct 2008 00:50:00 GMT

イレイジャではジェネリクスの何が消えるのかにて親クラスを継承する際に投入しているジェネリクス型パラメータはclassの情報として残っていることを述べました。

これを利用すると、

public class A<X> {

public class B<Y> extends A<Y> {

public class C extends B<String> {

といった継承階層があった場合に、C.classからA.classの<X>にどのような具象型が適用されているのか(上記例ではString型)をリフレクションで取得することができます。

Aの型パラメータのプレースホルダ<X>を取得
Bでsuper-classの型パラメータに渡されたTypeを取得
2のTypeが具象型ではなく型パラメータ<Y>なのでさらにサブクラスを走査
Cでsuper-classの型パラメータに渡されたTypeを取得
B<Y>のYにString型が渡されていることが分かるのでA<X>のXがStringであることが分かる

といった感じです。型階層がいくらあるのか分からないので再帰で処理するとよいでしょう。

サンプルプログラム

/** * 渡された型から継承階層を登って、 * 指定の親の型の指定の名前のジェネリクス型パラメータが * 継承の過程で何型で具現化されているかを走査して返す。 * @param clazz 走査開始する型 * @param targetClass 走査する対象のジェネリクス型パラメータを持つ型。 * 走査開始型の親である必要がある。 * @param targetTypeName 何型で具現化されたを確認したい型パラメータのプレースホルダ名 * @return 具現化された型 */ public static <T> Class<T> getGenericType( Class<?> clazz, Class<?> targetClass, String targetTypeName) { if (!targetClass.isAssignableFrom(clazz)) { throw new IllegalArgumentException( "型" + clazz.getName() + "は、型" + targetClass.getName() + "を継承していません"); } Stack<Class<?>> stack = new Stack<Class<?>>(); while (!targetClass.equals(clazz.getSuperclass())) { stack.push(clazz); clazz = clazz.getSuperclass(); } return getGenericTypeImpl(clazz, targetTypeName, stack); } /** * 型パラメータの具象型取得の実装。再帰処理される。 * @param clazz 現在の走査対象型 * @param targetTypeName 現在の走査対象のジェネリクス型パラメータ名 * @param stack 現在の走査対象型以下の継承階層が積まれたStack * @return 該当型パラメータの具現化された型 */ @SuppressWarnings("unchecked") private static <T> Class<T> getGenericTypeImpl(Class<?> clazz, String targetTypeName, Stack<Class<?>> stack) { TypeVariable<? extends Class<?>>[] superGenTypeAray = clazz.getSuperclass().getTypeParameters(); // 走査対象の型パラメータの名称(Tなど)から宣言のインデックスを取得 int index = 0; boolean existFlag = false; for (TypeVariable<? extends Class<?>> type : superGenTypeAray) { if (targetTypeName.equals(type.getName())) { existFlag = true; break; } index++; } if (!existFlag) { throw new IllegalArgumentException( targetTypeName + "に合致するジェネリクス型パラメータがみつかりません"); } // 走査対象の型パラメータが何型とされているのかを取得 ParameterizedType type = (ParameterizedType) clazz.getGenericSuperclass(); Type y = type.getActualTypeArguments()[index]; // 具象型で継承されている場合 if (y instanceof Class) { return (Class<T>)y; } // ジェネリックパラメータの場合 if (y instanceof TypeVariable) { TypeVariable<Class<?>> tv = (TypeVariable<Class<?>>)y; // 再帰して同名の型パラメータを継承階層を下りながら解決を試みる Class<?> sub = stack.pop(); return getGenericTypeImpl(sub, tv.getName(), stack); } // ジェネリック型パラメータを持つ型の場合 if (y instanceof ParameterizedType) { ParameterizedType pt = (ParameterizedType) y; return (Class<T>) pt.getRawType(); } throw new IllegalArgumentException("予期せぬ型 : " + y.toString() + " (" + y.getClass() + ")"); }

イレイジャではジェネリクスの何が消えるのか

凪瀬 — Mon, 13 Oct 2008 20:21:00 GMT

Javaのジェネリクスはコンパイル時に解決され、classファイルになった時にはジェネリクスの型情報は残されていません。そのためイレイジャ（型消去：type erasure）方式と呼ばれます。

と、ひとくちで言っても意味がよく分からないのでちょっと掘り下げてみましょう。

インスタンスからジェネリクスの型情報は拾えない

リフレクションを用いたとしても、インスタンスからジェネリクス型パラメータが何であるかを取得することはできません。

List<String> stringList = new ArrayList<String>();

のような変数stringListがあったとして、ここから<String>を取得するということができないのです。これが消えてしまった部分。

この変数stringListに対する各種操作において、その型の安全はコンパイル時に精査され、実行時にはあくまでObject型引数のメソッドを通したやりとりで動くのです。

クラス宣言に関わるジェネリクス型情報は拾える

しかし、型の宣言に関する部分はリフレクションで拾うことができます。ここが混乱する部分ですね。

親クラスを継承する際に投入しているジェネリクス型パラメータ
インターフェースを実装する際に投入しているジェネリクス型パラメータ
メソッドの引数・戻り値に用いられているジェネリックな型とそこに渡される型パラメータ
フィールドに用いられているジェネリックな型とそこに渡される型パラメータ

といった情報は拾えるわけです。

public class Piyo extends Hoge<String> implements IHoge<String> { private List<String> value; public List<String> get() { return this.value; } public void set(List<String> value) { this.value = value; } }

といったコードがあった場合、リフレクションで親クラスがHoge<String>型であることを拾えます。インターフェースも同等。また、フィールドやメソッドの戻り値・引数がList<String>型であることも拾うことができます。

ジェネリクスの代入を理解するその２

凪瀬 — Wed, 20 Aug 2008 00:08:00 GMT

前回はまず、ジェネリクス型パラメータを伴うList同士の代入互換性について述べました。

今回はそれらのListのadd()メソッドとget()メソッドについて見てきたいと思います。

なお、前回同様に C extends B, B extends A という継承関係があることとして以下話を進めます。

入力値の制約

前回で<? extends B>型には も <C>も <? extends C>も代入できると述べました。

List<? extends B> listBEx = new ArrayList<C>();

ということができるわけですね。さて、このlistBExにadd()をしてみるとしましょう。

listBEx.add(new B());

実は、これがコンパイルエラーになるのです。 List<? extends B>型には B型をadd()できないのです！

というのも、さきほどlistBExはArrayList<C>型で初期化しましたね。もし、Bをadd()できるとしたら、 ArrayList<C>型に B型がadd()されてしまうことになります。これでは矛盾してしまいますね。

ですから、List<? extends B>では型の安全性が破壊されないように、add()できるのは List<? extends B>に代入可能な List全てにadd()可能なものだけしかadd()できないように制約が掛けられます。

<? extends B>の範囲と ArrayList<C>の範囲、そしてBオブジェクトの位置を確認してみてください。 Bオブジェクトを型安全にadd()することができないのが分かるでしょうか？

では<? extends B>に対して何がadd()できるのでしょうか？

listBEx.add(null);

だけが可能なのです。使えませんね…。

さて、add()メソッドはこのような制約があるわけですが、get()メソッドなどは普通に使えます。この違いは何なのでしょうか？

これは、メソッドの引数にジェネリクス型パラメータが含まれる場合に発生する制約です。引数にジェネリクス型が含まれるadd()などではこのような制約が発生し、引数にジェネリクス型を含まないget()などでは制約は発生しません。

オブジェクトに対しての入力値がジェネリクスの代入互換性に矛盾しないようにするために存在する制約というわけなのです。

出力値の制約

List<? extends B>からの get()は問題なく行え、B型の変数に受け取ることができます。

B b = listBEx.get(0);

これは、<? extends B>に が代入されていようが <C>が代入されていようが、 get()で取り出されるオブジェクトは「B型を継承した何か」ですから、B型に安全にキャストできるわけです。

ここで、List<? super B>を考えてみましょう。

<? super B>には や <A>を代入することができます。

ということは、get()で取り出されるオブジェクトは、B型よりも上位のオブジェクト型である可能性があるわけです。このことから、<? super B>とした場合は全ての型のトップに位置するObject型でしかget()したオブジェクトを受け取ることができません。

Object o = listBSu.get(0);

これは前回の図を見ると分かることでしょう。再掲します。

入力値の制約　再訪

List<? super B>へのadd()はどうでしょうか？

図を見て分かるように、<? super B>に代入可能なや <A>は、すべてBオブジェクトを受け入れることができます。

そのため、ジェネリクスが<? super B>であれば B型をadd()することができます。

ジェネリクスの代入を理解するその１

凪瀬 — Mon, 18 Aug 2008 23:35:00 GMT

Javaのジェネリクスはかなり強力で、相当の型を表現できるのですが、代償として非常に複雑なものとなっています。

ややこしいのは、オブジェクト指向の部分の型の代入互換性と、ジェネリクス型パラメータの部分の代入互換性は、表現こそ似ているものの、その意味するところはまるで違うと言うことにあります。

端的には、C extends B, B extends Aの関係があるとして、型B にはサブクラスであるCをキャストなしに安全に代入することができます。

B b = new C();

しかし、ジェネリクス型パラメータの場合の

List listB = new ArrayList<C>();

はコンパイルエラーとなります。

List<? extends B> listBEx = new ArrayList<C>();

であれば代入が可能です。このように、同じ継承階層の型を扱うのにもかかわらず、その代入互換性が違うのですから混乱するのはやむなしと言えましょう。

ジェネリクス型パラメータの代入互換性

ジェネリクスでは、単に型をBと表現した場合、Bの階層だけが対象となります。

図のBの階層だけが対象になります。ですから、代入できるのは型だけです。

List listB = new ArrayList();

次に、<? extends B>と表現した場合、BとそのサブクラスであるCが含まれます。

<? extends B>にはも<C>も代入することができます。また、<? extends C>も代入することができます。

List<? extends B> listBEx; listBEx = new ArrayList(); listBEx = new ArrayList<C>(); List<? extends C> listCEx = new ArrayList<C>(); listBEx = listCEx;

また、ジェネリクスでは継承階層をスーパークラス側に遡る、<? super B>という記述もできます。この場合は、<? extends B>とは逆方向の範囲をカバーします。

この<? super B>にはや<A>や<? super A>を代入することができます。

List<? super B> listBSu; listBSu = new ArrayList(); listBSu = new ArrayList<A>(); List<? super A> listASu = new ArrayList<A>(); listBSu = listASu;

このように、<>の内側と外側では異なる代入規則があることをまずは明確に意識してください。

リフレクションでジェネリクスメソッドを扱う

凪瀬 — Mon, 16 Jun 2008 15:07:00 GMT

ふと訪れたblogで共変戻り値(covariant return types)を話題にしていたのですが、「コレ、JavaSE5.0からだったっけ？1.4だったような」、と思って調べるとやっぱり5.0でした orz

調べるとかつのりさんところ( 共変戻り値)で書いているなぁ…。自分の中でなぜか1.4だと思い込んでいる様子。この記憶はどこからやってきたのか…。

このあたりを見て、そういえばジェネリクスとリフレクションの話題があったなぁと思いだしたのでひとつ小噺を。

ジェネリクスの具象化とメソッドシグニチャ

さて、気を取り直して、この共変なオーバーライドですが、ジェネリクスの実装にはなくてはならないものです。

public interface Sample<T> { T hoge(); void piyo(T t); }

といったジェネリクス型パラメータを持つinterfaceがあったとして

public class SampleImpl implements Sample<String>{ public String hoge() { return null; } public void piyo(String t) { } }

というようにimplements時にStringとすると、hoge()の戻り型はStringクラスになるわけです。これは共変な戻り値になっているわけですね。

ジェネリクスのメソッドをリフレクションしたら

さて、先ほどのコード、piyo()がオーバーロードになっているのがわかりますか？

インターフェースの段階ではジェネリクス型パラメータのTが引数とされていました。これは実際的にはObject型となってしまうのですが、そうするとSampleImplのpiyo(String)はオーバーライドではなくオーバーロードになってしまいます。

SampleImpl impl = new SampleImpl(); Method m = impl.getClass().getMethod("piyo", Object.class); m.invoke(impl, "param");

ところが、上記のようにリフレクションでpiyo(Object)を呼び出すと、ちゃんとpiyo(String)が実行されます。これはどうしたことか！？

作られるclassの中をのぞいてみると面白いことがわかります。


  // Method descriptor #19 (Ljava/lang/String;)V

  // Stack: 0, Locals: 2

  public void piyo(java.lang.String t);


  // Method descriptor #22 (Ljava/lang/Object;)V

  // Stack: 2, Locals: 2

  public bridge synthetic void piyo(java.lang.Object arg0);

引数がStringのものと、Objectのものとふたつ作られているんですね。 "bridge synthetic"という修飾がついています。この元となったinterfaceのメソッドシグネチャ(メソッドを特定するためのメソッド名と引数型の組み合わせのこと)と同等のシグネチャで宣言されるメソッドがブリッジとなってpiyo(String)を呼び出しているのです。

このため、ジェネリクスをimplementsする際に具現化していても、interfaceや抽象クラスで宣言されたメソッドシグニチャを使ってMethodを取得してinvokeすることができるのです。

ジェネリクスを最大限活用するための設計技法 Stateパターン編

凪瀬 — Thu, 05 Jun 2008 21:17:00 GMT

今回はStateパターン編です。 Stateパターンはオブジェクト指向のポリモフィズムで動きを切り替えるという点で前回の Strategyパターンと同じです。

ただし、Stateパターンはそのインスタンス自身が「状態」を表現するという点で異なります。

電卓のUIのStateを作る

まず、Stateの使いどころですが、ここでは以前にわんくま同盟で取り上げられた電卓を例にしてみましょう。

επιστημηさんのところに電卓を状態遷移で捉える話題がでていたのですが、この状態遷移というのがStateパターンの使いどころになります。

電卓基本動作の状態遷移表

初期状態数値入力状態数式作成状態計算結果表示状態

数字入力なにかする
→数値入力状態なにかする
→数値入力状態なにかする
→数値入力状態なにかする
→数値入力状態

演算子入力なにかする
→初期状態なにかする
→数式作成状態なにかする
→数式作成状態なにかする
→数式作成状態

'='入力なにかする
→初期状態なにかする
→計算結果表示状態なにかする
→計算結果表示状態なにかする
→計算結果表示状態

'C'入力なにかする
→初期状態なにかする
→初期状態なにかする
→初期状態なにかする
→初期状態

電卓基本動作の状態遷移表
	初期状態	数値入力状態	数式作成状態	計算結果表示状態
数字入力	なにかする →数値入力状態	なにかする →数値入力状態	なにかする →数値入力状態	なにかする →数値入力状態
演算子入力	なにかする →初期状態	なにかする →数式作成状態	なにかする →数式作成状態	なにかする →数式作成状態
'='入力	なにかする →初期状態	なにかする →計算結果表示状態	なにかする →計算結果表示状態	なにかする →計算結果表示状態
'C'入力	なにかする →初期状態	なにかする →初期状態	なにかする →初期状態	なにかする →初期状態

この、「初期状態」「数値入力状態」「数式作成状態」「計算結果表示状態」がStateパターンではオブジェクトのインスタンスで表現されます。そして、そのクラスには「数字入力」「演算子入力」「'='入力」「'C'入力」の4つのメソッドが定義されます。

Java/** @param <R> Stateの具象型 */ public interface State<R extends State> { /** 数値の入力 * @return 遷移するState. 以下同じ */ R onInputNumber(int num); /** 演算子の入力 */ R onInputOperation(Operation ope); /** '='の入力 */ R onInputEquale(); /** 'C'の入力 */ R onInputClear(); }

C#public interface State<R> where R : State { /// <summary>数値の入力</summary> /// <returns>遷移するState. 以下同じ</returns> R onInputNumber(int num); /// <summary>演算子の入力</summary> R onInputOperation(Operation ope); /// <summary>'='の入力</summary> R onInputEquale(); /// <summary>'C'の入力</summary> R onInputClear(); }

より抽象的にすることで再利用性を持たせる

通常のStateパターンだと、この時点で具象型を用いるのでジェネリクスの出番はないところですが、 電卓と同じユーザインターフェースを持つ別のアプリケーションを作れるようにジェネリクスで抽象化しておきます。

ご覧の通り、各メソッドは処理をした上で次に遷移するべきStateを返すようになっています。このときに自信の型を返したいので自己言及するジェネリクス( Java版、 C#版) で取り上げた手法を用います。

これらの実装を作る際にはジェネリクス(サンプルソースのR)を具象化するわけですが、この型は電卓用であれば電卓用、同一UIを用いた別の何かであればそれ用に独自に拡張します。 電卓用のStateと別の何かのStateは混同して利用されることはありません。

つまり、このUIを共通に提供するような再利用性の高いフレームワークを設計する場合でないと、このようなStateパターンの多様な拡張性を持たせると言う設計は活きてこないのです。

逆に、このようなジェネリクスを活用することで、今まで再利用が不可能だと思っていたパーツを再利用可能な形でライブラリとすることができます。

補足

Javaの場合はさらに Strategyのインスタンスをenumで扱うで取り上げたように、Stateのインスタンスをenum化することができます。

ジェネリクスを最大限活用するための設計技法 Strategyパターン編

凪瀬 — Fri, 30 May 2008 17:59:00 GMT

前回は振りだけでしたが、今回からデザインパターンとの絡ませ方を紹介してきます。

Strategyパターンの実例

Strategyパターンの実例として java.lang.Comparator および System.Collections.Generic.IComparer によるソートを取り上げます。

Strategyパターンによって切り替わるのは、ソートのアルゴリズムではなく、二つのオブジェクトの比較方法です。ここではUserというオブジェクトを想定してみます。

Javapublic class User { public String name; public int age; }

このUserのListがあるとして、これを名前(name)順にソートするのか、あるいは年齢(age)順にソートするのかといったことをStrategyパターンで切り替えるわけです。

そのためのStrategyのインターフェースが先に挙げた java.lang.Comparator および System.Collections.Generic.IComparer となるわけです。

これらの実装クラスをStrategyとしてソートのメソッドに渡すことで、ソート処理の動きを切り替えることが出来ているわけです。

Java Strategyの実装public class UserNameComparator implements Comparator<User> { public int compare(User user1, User user2) { return user1.name.compareTo(user2.name); } }

Java ソート処理の呼び出し List<User> list = new ArrayList<User>(); list.add(new User("ABC", 10)); list.add(new User("BCD", 12)); list.add(new User("CDE", 8)); Collections.sort(list, new UserNameComparator());

C# Strategyの実装 public class UserNameComparer : IComparer<User> { public int Compare(User user1, User user2) { return user1.name.CompareTo(user2); } }

C# ソート処理の呼び出し List<User> list = new List<User>(); list.add(new User("ABC", 10)); list.add(new User("BCD", 12)); list.add(new User("CDE", 8)); list.Sort(new UserNameComparer());

ジェネリクスによる具象化

さて、ここでジェネリクスによる具象化がどこで行われるかを見てみましょう。

まずはソート処理を呼び出す部分。こちらではListに入るオブジェクト型を明示しています。ここのソースコード状ではジェネリクス型パラメータは具象化されているわけです。

そして呼び出されたソート処理の中身、つまるところクラスライブラリ内では当然ながら StrategyであるComparatorやIComparerのジェネリクス型は具象化されない状態で処理されます。ですから、ソートのアルゴリズム中ではListのオブジェクトが何型かを意識してはいけません。動的にinstanceofとかで調べることはできますが、覗き見はしてはダメ。

そして、実際のStrategyの具象型部分。ここでは比較を行うオブジェクトは具体化されています。型が具体化されているのでキャストなどは不要で、Listに格納される型に合わせた処理をそのまま記述できます。

キセルのような中抜きの抽象化

ジェネリクスがない場合、Strategyの実装クラスでキャストしなくてはなりません。事実、ジェネリクス搭載前のJavaではそのようにコードを書かざるを得ませんでした。

ソートのアルゴリズムを抽象化したら、比較のアルゴリズムの引数まで抽象型(Object型)になってしまっていたのです。これをジェネリクスによって具象化することができるようになりました。

中間のソートのアルゴリズム中では型は抽象的に、呼び出し部分およびStrategyの実装部分では具体的にというわがままな抽象化がジェネリクスによって可能となったのです。

ジェネリクスを最大限活用するための設計技法

凪瀬 — Wed, 28 May 2008 23:32:00 GMT

先日の自己言及するジェネリクス(Java版 /C#版)を書いていて見えてきたことがあります。

ジェネリクスの具象型の与え方は2通りあり、そしてそれは、違う用途で用いられる、ということです。

コレクション型で用いられるジェネリクス

JavaやC#のジェネリクスで馴染みが深いのはコレクションAPIでのジェネリクスでしょう。つまるところJavaのjava.util.Listや、 C#のSystem.Collections.Generic.List といったクラスです。

これらのクラスは通常、newする際にジェネリクスの型パラメータに具象型を指定して具体化させます。

JavaList<String> stringList = new ArrayList<String>();

C#List<String> stringList = new List<String>();

このタイプの使い方はよく用いられているようですが、もうひとつのジェネリクス型を具象化させる方法を使えていますか？

継承を用いた具象化

ジェネリクス型を具象化させるもうひとつの方法はクラスの継承の際に型を渡す手法です。

Javapublic class StringList extends ArrayList<String> { // ... }

C#public class StringList : List<String> { // ... }

サンプルではListの継承としていますが、通常こちらの使い方はコレクションAPIに対しては使われません。オブジェクト指向の継承の機能を利用して再利用可能な抽象化を行おうとする際に用います。

デザインパターンとの併用

この手法はデザインパターンと併用することでクラス設計に深みが生まれます。相性の良いGoFデザインパターンには以下のものが挙げられると思います。

ポリモフィズムで条件分岐するパターン（Strategy、State、Abstract Factory）
複雑な生成を隠ぺいするパターン(Builder、Factory Method)
構造に纏わるパターンの定石部分の再利用(Composite、Visitor)

ここに挙げたデザインパターン以外にも適用可能だとは思いますが、特徴的なのは上記のものだと考えています。これらのデザインパターンでの具体的なジェネリクスの使い方は次回以降で詳しく掘り下げてみたいと思います。

自己言及するジェネリクス C#版

凪瀬 — Mon, 26 May 2008 22:26:00 GMT

自己言及するジェネリクスをC#でも書いてみました。

namespace Sample { public class HogeA<H> where H : HogeA<H> { public H GetHoge(){return null;} } public class HogeB : HogeA<HogeB>{} public class Test { public static void Main(String[] args) { HogeB hogeB = new HogeB(); HogeB hogeB2 = hogeB.GetHoge(); } } }

やってることは一緒ですね。

自己言及するジェネリクス

凪瀬 — Sun, 25 May 2008 18:06:00 GMT

先日、Strategyのインスタンスをenumで扱うで取り上げたようにJavaのenumはメソッドを宣言することができます。JavaSE5.0でenumを追加する際、既存の型システムを利用して作られているため、Javaのenumはクラスなのです。

このenumの親クラスとなるのがjava.lang.Enumクラスなのですが、宣言が変わっていて、ジェネリクスの型パラメータが自身の拡張なのですね。

Enum<E extends Enum<E>>

これと同じような構造を持つクラスを作った場合、型安全にインスタンス化できません。

public class Hoge<H extends Hoge<H>> { public static void main(String[] args) { Hoge<Hoge<Hoge<...>>> hoge = new Hoge<Hoge<Hoge<...>>>() } }

型パラメータが再帰してしまうため、パラメータを与えることができない。これをずっと疑問に思っていたんですが、自作のHEXのフレームワークのリファクタリングをやっていて似たような構造が出来た時に、こうした自己言及するジェネリクスの使い方がわかりました。

この自己言及型のジェネリクスは継承する際に型パラメータに具象型を渡すことで実体化させることができます。

public class Hoge<H extends Hoge<H>> { public H hoge() { return null; } }

public class Piyo extends Hoge<Piyo> { public static void main(String[] args) { Piyo piyo = new Piyo(); Piyo piyo2 = piyo.hoge(); } }

こんな感じですね。Hoge#hoge()メソッドは戻り型をHogeではなく、ジェネリクスでHとしています。そのため、Hogeの継承型であるPiyoのhoge()メソッドは戻り型がHogeではなくてPiyo型になります。サンプルソース中の強調部分を見てください。キャストしていませんよね。

もしもメソッドがHoge型を返すようにしているような場合では Hogeの子クラスであるPiyo型をreturnすることはできますが、受け手、つまりメソッドの呼び出し元ではキャストを行わないと代入ができません。そして、そのキャストはダウンキャストであって型安全ではありません。

このように、自身のインスタンスを返すメソッドがあったとして、そのクラス(ここではHoge)継承された場合にそのメソッドが継承した子クラス(ここではPiyo)を返すようにすることができるのです。

これは、自信のインスタンスを直接返す他、自信の型をジェネリクスとして用いているメソッドなどを定義する場合にも使えます。