この実装には、今度こそリフレクションを利用することとなる。 public override IMessage Invoke(IMessage msg) { ：（前略） IMethodCallMessage req = msg as IMethodCallMessage; // FieldGetter と FeildSetter に対して独自の実装を提供する if ((req.M…

幸運なことに、internal method の呼び出しは RemotingServices.ExecuteMessage() でサポートされているらしく、問題なく実行することができる。 よって、問題となるのは internal field の取得に限定された。ここで、問題解決には、Remoting と MarshalByRe…

その問題点とは、RemotingServices.ExecuteMessage() によって実行できないメッセージが存在するのだ。 たとえば、Control の派生クラスに対して MethodLogger を作成しフォームに追加するだけで "Control.parent が見つかりません。" といった内容の例外が…

Form1Proxy は Form1 クラス専用ではあるが、これを任意のクラスに対して拡張することは一見、難しくない。 呼び出しを記録するインスタンスを受け取り、そのインスタンスに対応した proxy を生成するだけである。 public class MethodLogger : RealProxy { …

RemotingServices.ExecuteMessage を使った実装は、非常に簡単ではあるものの、proxy の管理に関する問題として、this の取り扱いがある。 public class Form1 : MarshalByRefObject, ICloneable { private int current = 0; public int Add(int value) { ch…

MarshalByRefObject クラスがいったい何なのか、リファレンスを開いてみてもすぐには理解できないかもしれない。 とりあえず、MarshalByRefObject クラスの派生クラスじゃないとダメなんだと機械的に覚える程度で問題はない。 覚えておくほうがよいと思われ…

このような問題を解決するには、リフレクションを利用するというのがすぐに思いつく手段ではあるが、*1 RealProxy クラスや ReturnMessage クラス同様に、IMethodCallMessage を処理する機能が .NET によって最初から用意されている。 private Form1 form1 =…

すでに予想ができていることとは思うが、前回の方式では Form1 クラスと Form1Proxy クラス双方で、まったく同じロジックとデータを持たなくてはならない。*1 このままでは対象のクラスの中身を完全に理解していないと stub の実装ができないことになってし…

前回までのお話 メソッド呼び出しを記録するため、.NET Remoting などで利用される TransparentProxy を使い、特定のクラスのメソッド呼び出しを受け取る RealProxy 派生クラスを作成するまで。前回、まだ動かないという状態になっているのを、今回はとりあ…