ジェネリクス

複数通貨のMoneyをジェネリクスで作る

凪瀬 — Tue, 19 May 2009 00:54:00 GMT

Kanazawa.processではテスト駆動開発入門を読んで、テスト駆動開発を学びました。その本でのテスト駆動開発のサンプルとして挙がっていたテーマは複数通貨のMoneyを作るというものでした。

Dollarという米ドルを表現するオブジェクトを作り、Francというスイス・フランを表すオブジェクトを作り、そしてMoneyというオブジェクトに統合していくというリファクタリングの過程を経ています。

これをジェネリクスを使って設計したらどうなるでしょうか。

public abstract class Money<T extends Money<T>> { public abstract T add(Money<?> m); }

Moneyオブジェクトに演算用のメソッドadd()を定義します。引き算や掛け算など要求に合わせて各種用意するといいでしょう。

Money<T extends Money<T>> という型変数の宣言方法は自己言及するジェネリクスの稿で取り上げた手法です。add()の戻り型をTとしておくことで具象型自身の型を返させることができます。

これをDollarやFrancでオーバーライドして実装します。

public class Dollar extends Money<Dollar> { @Override public Dollar add(Money<?> m) { // ... } }

こうすることで、Dollarのadd()はDollar型で返るわけです。しかし、これだけだとDollarやFrancといった通貨単位ごとにadd()の実装を施さねばなりません。 protectedなファクトリーメソッドを用意して、オブジェクトの生成を具象型に委譲することでスーパークラスであるMoney型で統一的にadd()を記述することができます。

public abstract class Money<T extends Money<T>> { /** 為替レート */ Map<Class<? extends Money<?>>, Map<Class<? extends Money<?>>, Double>> rateMap; /** 値 */ protected double value; /** 加算メソッドの共通実装 */ public T add(Money<?> m) { double rate = rateMap.get(this.getClass()).get(m.getClass()); return getInstance(this.value + m.value * rate); } /** 具象型の生成 */ protected abstract T getInstance(double value); /** コンストラクタ */ protected Money(double value) { this.value = value; } }

こうした手法で通貨単位ごとに型を作って何が嬉しいかと言えば、ドル建てである場所にスイス・フランの型が紛れ込んだ場合にコンパイルエラーにすることができるという点です。

設計にはいろんな手法がありますし、それぞれにメリット、デメリットがあるので要求に合わせて柔軟に選べるようにしたいものですね。

大阪勉強会#28 ジェネリクスを使おう！

凪瀬 — Sun, 22 Mar 2009 22:28:00 GMT

春分の日に大阪勉強会#28でセッションやってきました。

今回はジェネリクスということで難度の高いネタなんですが、狙いとしてはジェネリクスを使えるようになった先の世界はこんな感じだよ、というのが伝えられたらいいなということで、細かいところはおいておいて設計とかでこんな感じで役立つよという話をメインにしていました。後半部分ですね。

僕としては自重なしにマニアックなネタをしゃべったんですっきり。セッション聞いてもやもやした人は勉強してすっきりさせてください（鬼

ジェネリックメソッド

ジェネリックメソッドについては意図的にスルーしていたのですが、知りたいと言う人のためにさらっと説明しておくと、型変数がメソッドになっただけです。型変数にまつわる制約などはジェネリッククラスの場合の型変数と変わりませんね。

Javaのジェネリックメソッドで特記するべき点は型推論が効くと言う点なのですが、これがまたえらいややこしい話題なのでこれまたセッションではちょっと説明しきれない代物ですね。もっとも私もジェネリクスの型推論については語れるほど理解できていませんし。

キャストのシンタックスシュガー

ジェネリクスを「キャストのシンタックスシュガー」と言った人がいたと記憶していますが、この表現では大事なことを見落としています。確かにキャストの発生する場所全てで漏れなく確実にキャストを入れれるのであれば、ジェネリクスを使った場合と同じ動きをするプログラムになるのですが、「漏れなく確実に」がとても難しいのですね。

このキャストという横断的関心事、つまるところアスペクト指向的なテーマをコンパイル時の全走査で解決しているというのがJavaのジェネリクスです。大事なのは「漏れなく確実に」という部分。「キャストのシンタックスシュガー」という表現ではこの一番肝心なところが伝わらないので表現としてはイマイチではないでしょうか。

ソースコードとか

サンプルのソースコードとかはやっつけで作ってたんで綺麗にまとめてWeb化したいところですね。C#版とかScala版とかを手伝ってくれる人がいたら歓迎します。

ジェネリクス関連エントリ

過去に書いたジェネリクス関連エントリがありますので参考にしてください。

凪瀬blog - ジェネリクス

再帰型のジェネリクス型変数の境界

凪瀬 — Fri, 23 Jan 2009 23:45:00 GMT

先日ジェネリクスで引っ掛かった点をメモ。

自己言及するジェネリクスで述べたような具象型に具象型自身の型を扱わせることをもくろんだ型を作った場合の話。

public class GenericsTest { static abstract class S<T extends S<T>> {} static class A extends S<A> {} static class B extends A {} static class C extends S<A> {} static class X1<T extends S<T>>{} static class X2<T extends S<?>>{} static class X3<T extends S<? super T>>{} public static void main(String[] args) { X1<A> x1A; // OK X1 x1B; // NG X1<C> x1C; // NG X2<A> x2A; // OK X2 x2B; // OK X2<C> x2C; // OK X3<A> x3A; // OK X3 x3B; // OK X3<C> x3C; // NG } }

Sが親となるクラスで<T extends S<T>>という境界をもつジェネリクス型変数Tを持ちます。サブクラスであるAはこのTにA自身を渡すことで、Sクラス中にT型で宣言した部分をA型にすることができるのですね。

そのA型を継承したクラスBを考えた場合、BはS<A>を継承しているのでB extends S<A>ということになります。なのでX1の境界<T extends S<T>>に合致しません。

こうした型を受け入れれるように規制を緩めたのがX2で<T extends S<?>>としています。この場合、穴ができてCのようなAのサブクラスでもないのにSの型変数TにAを渡したような歪なクラスを宣言した場合に許容されてしまいます(x2C部分)。クラスS中に表現されるTを具象型自身にするという趣旨からすればこのような歪な型は許容したくありません。 T型の戻り値のメソッドでreturn this;とか書きたいわけです。

なので正確に型を表現するとしたならば<T extends S<? super T>>とします。これでAはもちろん、AのサブクラスであるBも許容され、歪なCは弾くことができます。

ジェネリクスの代入互換の補足

凪瀬 — Sun, 04 Jan 2009 18:06:00 GMT

ジェネリクスの代入を理解するその２に以下の質問を頂きました。

インタフェースIFをAが実装しているとし、
A←B←Cの関係はそのままの場合で下記処理をコンパイルしたとします。
List<? super B> list = new ArrayList<IF>
list.add(new B()); //1
list.add(new A()); //2
list.add(new C()); //3

この場合も2はエラーとなってしまいます。
ArrayList<IF>にAをaddしても矛盾しないと思うのですが、
これは何故なのでしょうか？？

変数list はList<? super B>型ですから、ArrayList型を代入することができますよね。

List<? super B> list = new ArrayList<IF>(); list = new ArrayList(); list.add(new A());

としたらどうなるでしょうか？
ArrayListにAをaddすることになりますね。落ち着いて考えてみてください。List<? super B> list = new ArrayList<A>();のケースと同じです。

コンパイルによる静的な型チェックは、いつ変数listにどういう型を代入されたかを追跡しません。
なので代入して矛盾が発生する可能性がある場合にすべてコンパイルエラーとします。

古いエントリになりますが、ジェネリクスと代入と落とし穴2も併せてご覧ください。

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

凪瀬 — 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化することができます。