2012/11/27 Yokohama.groovy #9 #yokohamagroovy
-
- いいね！0
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose で、最初の話に戻りますが、なにかのClassのinvokeMethodを実装するというのは、GroovyObjectのinvokeMethodをオーバーライドすることであり、metaClassのinvokeMethodとは別物です。
2012-11-28 00:18:31
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose 実際のメソッド解決は少し複雑なので、さきの説明と少しずれるのですが、基本的には次のように解決されます。メソッドがない -> GroovyObject.invokeMethod メソッドがある -> MetaClass.invokeMethod
2012-11-28 00:22:30
とーます
@grimrose
ということは、あの題名は「GroovyObject#invokeMethodのオーバーライドとMetaClass#invokeMethodの違い」が正しいのか…
2012-11-28 00:23:47
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose メソッドがあるし、Interceptableを継承している -> interceptable.invokeMethod になります。Closureの場合はClosure.invokeMethod,Javaの場合はクラス用のMetaClass.invoke
2012-11-28 00:24:10
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose なので先の例の、メソッドがない & invokeMethodのオーバーライド -> invokeMethodが実行される メソッドがない & metaClass.invokeMethodのオーバーライド -> 全てのメソッドがオーバーライドされるになります。
2012-11-28 00:26:06
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose メソッドが存在する限りは基本的にmetaClass経由なのでそこをオーバーライドしているので、metaClass.invokeMethodはそのような振る舞いになるわけです。
2012-11-28 00:27:11
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose で、フックはするんだけど、それをそのまま呼ぶという事は可能なので、例えば多いのは、メソッドの呼び出し直前直後にパラメータと返り値をログに出力するmetaClassを用意して、全てのクラスにそれを注入するとか、Classとして実装して継承させるとかします。
2012-11-28 00:29:05
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@grimrose ログ出力だとたんなるフックなのですが、metaClassはかなり柔軟にできているので、まったく別のオブジェクトとして実行するということもできます。なのでDSLというか、かなり無茶をできる仕様にはなっていますね。ざっくりと説明してみました。長文失礼。
2012-11-28 00:31:43
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
GroovyのMOPというか、MetaClassの触りを説明してみたが、Groovy基礎の触りでもこんなに文字数必要なのか。。。
2012-11-28 00:32:53