ITSS事業部なかざとです。

情報システム部門で業務システムのコーディングをされている方、IT企業や派遣先で実装を担当されている方、様々な形でプログラムを書いている方がいらっしゃると思います。

最近では当たり前になってしまい、あまり騒がれなくなってしまった「オブジェクト指向」という言葉ですが、今となっては避けられないテクノロジーになってきています。

オブジェクト指向の恩恵の一つに、「ダイナミック」というキーワードを私は思いつきます。なんでも「オブジェクト」と捉える考え方ですので、極論を言うとメソッドになんでも渡せますしなんでも返せます。

昔は「将来起こるであろう何か」を想定したプログラミングって結構難しかったのではないかと思います。

創るものが小さかったり、一度作ったら大きなイベントが無い限り業務が変わらないといった場合は、そのビジネスロジック専用のクラスを用意するといった作り方をするのではないでしょうか？

しかし、あとで「あれやこれやを追加して欲しい」とかお客様に言われることが、どうしても浮かんでしまうんですよね。。。

で！　救世主「Reflection」。

例えば、データベースに「ロードモジュール名＋アセンブリ名」を持つテーブルを持たせておき、これを参照してアプリ側で機能を呼び出すなんて芸当ができてしまう。更には文字列で定義したメソッド実行も。　なんて素晴らしい！

私も正直魅了されました。

しかし！

踏み留まって将来をよく考えてみてください。システムには必ず(と、言ってよい程)バグがあります。それを他の方や皆さんの後輩が解析をしなければならない事が発生することを。

Reflection を使うと動作を行っている根源や関連部分を特定するのが凄く大変です。VisualStudio なんかである「右クリックコマンド一発で探り当てる」という芸当は使えません。grep (UNIXユーザーには欠かせない)の嵐で元を追うしかありません。

「便利(ダイナミック)」と「保守性」が仲良くなることはなかなか難しいでしょう。

私は、Reflection を使う基準を「1.どうしても使わないと要件を実現できない場合」または「使うことで利便性と拡張性が格段に良くなる」という２つに、「最小限の回数で」が満たせる場合のみと決めています。

「気ままに Reflection」には注意しましょう！
(杏里さんゴメンナサイ)