■

メソッド名を渡して処理内容を実行する。
これを実現するのにはReflectionがいいとおもっていた。
JavaではMethodクラスを使ってみたし、それで実装もできてた。
それで設計してたし、実装もする予定だった。
実行速度を測るテストもしてみた。
単純なstringを返すだけのメソッド呼び出しで実験してみたら、
10万回でだいたい0.1秒くらいの差になった。
Releaseビルドで0.09秒：0.20秒くらいの差。
3〜4倍くらいの速度差ですな。
でもこれでも用途箇所を考えれば無視できそうなもんだと結論をだした。

けれども。

C#にはDelegateがあるではありませんかと、
その後教えられた。
実行メソッドをあらかじめ定義しておくことで、
そのメソッドを呼び出せるようになる仕組み。
(・∀・)イイ!
実行メソッドを定義するので、
単純な時間を比較するためにはそれも考慮せなならん。
ってことに気をつけながら実行速度を測ってみた。
10万回実行で0秒と0.02秒くらい。
あれ？
なんでこんなに違うの？
さっきと同じメソッド実行したら0秒？
おかしいなと思ってみたら、さっきのテストでは実行クラスのインスタンスも10万回作成するようになってた。
やべぇやべぇ。
早速修正してみたら単純実行とReflectionの速度差は如実になったように感じられますな。
ちなみにDelegateだとstringを単純に返すメソッドという同条件下で
100万回の実行時間は0.06：0.08。

っとはいえ、実際に実装する形式はstringを返すだけじゃない。
多態性を持たせ、なんでもかんでもここでやるといった意気込みを反映させるためには、
もう一工夫いる。

ってことで、スーパークラスをつくり、スーパークラスにて処理を書くけれども、
実際はサブクラスのインスタンスを扱うようなテストプログラムを作って実行してみた。
さすがにstringの単純実行よりは速度が落ちていて、
10万回実行でで「メソッド実行：delegateで実行」＝「0.11：0.19」くらいの差になった。
なんだかReflectionとそんなに差がなくなってきた。

それでも、呼び出し時に関数名という文字列を渡すよりは、
関数そのものを定義するほうが、ソースを読み解く上で、
結びつきが強く感じられるような気がしたのでdelegateを選択することにした。

いやあれだね。
delegateを使用することを考えた設計。
すんげーめんどいな(´∀｀)
ここでメソッドを呼び出す設定を行ったうえで、
そのインスタンスをここの引数に指定すると、
呼び出された先で実行される。
関数そのものをあらかじめ設定して、クラスのように扱うから〜
っと頭じゃ理屈をわかっていても、いざ考え始めるとウニになりそうな勢いです。

そのかわり望み通りな動きをするとかなり幸せな気分を味わえた。
おれさいこーd(゜Д゜)！

さて。
ここからソースを綺麗に補修する作業だ。