目次
参考にするリンク
- むいみこむ
- http://muimi.com/j/reflection/#DynamicProxy
- リフレクション#DynamicProxy
- Proxy パターン - Wikipedia
- http://ja.wikipedia.org/wiki/Proxy_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
存在するかどうか分からない外部提供クラス
個人で作成しているときは気にならないようなことが、企業では起こる。
その1つとして、外部提供の例を考えてみる。
システムを構築する環境を絞るということ
通常、システムを組んでいるときは環境を絞ることができる。
ここで言う環境とは、自分のシステムが動作する場所ということ。
たとえばWindowsアプリならWindows上で動作するのは確実である。
それはもちろんコンフィデンシャルな側面もある。
しかし一方で、環境を制限すると良いこともある。
その中でも「あるかどうか分からない」を回避することができることは大きい。
Javaに限らず、オブジェクト指向の概念ではsuperクラスが存在する。
システムの中で汎化・部品化する際にはとても有益なものだ。
だが他の環境との接続部分に使われると、話がややこしくなる。
そう、Javaで言えば「クラスをimportする」ことができるのか、できないのか、だ。
外部提供されたクラスが「見えない」ということ
Javaで言う「クラスをimportする」とは、そのクラスが確実に存在することを意味する。
import文はパッケージ名指定でクラスを確定させるので、
たとえ同名のクラスが別パッケージにあっても見つけることができる。
外部提供されるクラス郡は当然、「こちらに見える」ように提供されるのだから、
もちろん通常はimport文が書けるし、それで問題ない。
しかし、絶対にimport文が書けるとは限らない。
たとえば、こちらのシステムと外部提供システムがあったとする。
- こちらのシステムはどのような環境でも動作する。
- 外部提供のシステムは一部のハードウェアがある場合に動作する。
このとき
という条件が付くと排他をする必要があるのだが、
- 排他処理そのものが、外部提供のシステムが乗ってないと使わない。
ということが、無視できない程度の頻度で起こる。
いや、というか実際に起こった。
クラスはClass.newInstance()。でもInterfaceのインスタンス化は?
外部提供のクラスが存在するか分からない場合、import文は書けない。
それどころか、以下のようにクラス名を書くことすらできない。
public static void main
(String[] args
) { 外部提供クラス external = new 外部提供クラス();
}
こういう時は、Javaのリフレクションを使って、
public static void main
(String[] args
) { try {
Class<?> cls = Class.forName("test.外部提供クラス");
Object instance
= cls.
newInstance(); }
}
などとしながらinstanceを拾い上げる。
java.lang.reflect.Constructor<T>を使うこともあるだろう。
これで、こちらからメソッドを呼び出すのは、ほぼ、困らなくなる。
だがここで問題が起きた。
- 外部提供のシステムが排他を解除する際に、少し時間が掛かる。
- 排他システムでは、排他解除の通知がきたらこちらにコールバックを返す仕様。
- このコールバックは排他システム側でInterfaceが用意されている。
さぁ、排他システムが乗っているかどうか分からない状況だ。
このコールバック用のInterfaceを実装したインスタンスを、どう渡す?
外部提供のInterfaceをインスタンス化する
というか、正確にはこちらからInterfaceを Proxy にする。
標準のJavaに用意されていて、
- java.lang.reflect.Proxy
- java.lang.reflect.InvocationHandler
を使って、相手が呼び出したメソッドをこちらにコールバックさせる。
Proxyそのものは・・・「デザインパターン Proxy」あたりで検索するといいかも。
提供元と呼び出しの構成
提供元さんには敢えて、漢字使ったクラスとインターフェースを準備いただいた。
理由はね、ほら、実際に提供してきたとあるとこを尊重してさ。
Main.java
使ってみる。
Listenerが提供されているということは、
普通、Listenerとして登録するクラスがあると思う。
ただ動的にInterfaceをインスタンス化する必要があるときは
これも見えないと思うので、Reflectionを使って登録することになるだろう。
Proxy.newProxyInstance(ClassLoader, Class<?>[], InvocationHandler)
で取得したインスタンスが、実際に上手くやってくれるインスタンス。
これをListenerとして登録する。
// コールバックをもらうためのHandler
// 提供元のインタフェースのクラス型を拾ってくる。
Class<?> clsImpl = Class.forName("test.外部提供インタフェース");
// その他、必要なもの
Class<?>[] interfaces = new Class<?>[] { clsImpl };
// Proxy用のインスタンス生成。
// 実際に提供元に渡すのはこのインスタンス。
Object listener
= Proxy.
newProxyInstance(loader, interfaces, handler
);
// 提供元のListener登録するクラス型を拾ってくる。
Class<?> clsExtn = Class.forName("test.外部提供クラス");
// 適当にインスタンスにしてListener登録
Method SETLISTENER
= clsExtn.
getMethod("setListener", interfaces
); Object instExtn
= clsExtn.
newInstance(); SETLISTENER.
invoke(instExtn,
new Object[] { listener
});
で、このInvocationHandlerというのが実際にinvokeを受ける。
- result = getClass().getMethod(name, method.getParameterTypes()).invoke(this, args);
というのはちょっと強引な気もするけど、
そもそも強引にProxyにしているのだから今更感満載でいいかなーって。
@Override
// proxyをここでログ出すと
// 「toString() の invoke が呼ばれる。」
// とか意味不明なことになってStackOverflowで落ちるので気をつけるように。
L.d("method=[%s]", method);
if (args != null) {
L.
d("args=%s",
Arrays.
asList(args
)); }
String name
= method.
getName(); // 面倒なときの呼び出し
result = getClass().getMethod(name, method.getParameterTypes()).invoke(this, args);
/* こっちはこっちで面倒である
if ("call".equals(name)) {
call();
} else if ("callcall".equals(name)) {
result = callcall((Integer) args[0]);
}
//*/
return result;
}
public void call() {
L.std();
}
public int callcall(int a) {
L.std("a = %d", a);
return a;
}
}
実行結果
添付のファイルを実行すると以下のようになる。
Main.java
Main : main() Start.
Main : main() clsImpl = interface test.外部提供インタフェース
Main : main() handler = test.Main$InterfaceHandler@201f9
外部提供クラス : setListener() Start.
Main$InterfaceHandler: invoke() method=[public abstract int test.外部提供インタフェース.callcall(int)]
Main$InterfaceHandler: invoke() args=[10]
Main$InterfaceHandler: callcall() Start : a = 10
外部提供クラス : setListener() End.
Main : main() End.
まとめ
Interfaceをインスタンス化する方法があることを示した。
これには以下のクラスを使用してProxyを提供元に登録するものだ。
- java.lang.reflect.Proxy
- java.lang.reflect.InvocationHandler
確実に相手が存在する環境では、当然ながらimplementsを利用すべき。
しかし存在が不確定な相手とのInterfaceを張る場合は注意が必要になる。
それでも、環境毎に分けることが可能なら、やはりimplementsを利用すべき。
この手法が当てはまるのは、主に相手のせいではない。
こちら側が何らかの理由で環境を分けられない立場にあるためである。
関連リンク
取得中です。
&trackback()
最終更新:2012年02月26日 22:42