リフレクションはなぜ使ってはいけないのか

言語や用法によります。使っていいところでは使っていいです。今回はC#の話に限定します。もっといえばアプリケーションコードを想定。

よく言われる実行速度は大きな問題にはなりません。もちろんユースケースによりますが、計算機性能が上がった今では実行速度はそこまでシビアな要求にはなりません。 例えばWebでは他の通信の方がロスが大きいです。

真に問題なのは静的解析が効かなくなることです。呼び出されるメソッドが間違っていようがコンパイル時にエラーが出なくなってしまいます。

加えてエディタの機能にも問題が出ます。C#だとVisual Studioを使っていることが多いですが、 例えばメソッドがどこからどれだけ使われているか調べることができます。リフレクションだとこれがわかりません。 例えばメソッドの名前を変更すると参照している場所の名前も全て変更できます。リフレクションでは変更が付いてきません。

エディタはソースそのものではありません。が、開発を便利にするエディタを使用してソースを書いていれば、その機能があること前提のソースになります。機能を失くせば必ず変更時に見落としが発生します。

この問題に対処する方法は、テストコードを書いて動作を保証することです。これならリフレクションが使われていても問題はありません。

C#は型があるのでテストコードを書かなくても割と何とかなります。本当に。書いてない現場だって多数あるでしょう。 ですがリフレクションが出てくれば話が違います。 リフレクションを書くような需要が出てくれば一緒にテストコードを書くことを意識しなければなりません。

ちなみにC#ならReflectionTypeLoadExceptionとか気を付けたいです。わかっていれば踏みませんがリフレクションはわかっている率があまり高くないと感じます。