仕事を干されている社内ニートなので黙々とRuby勉強中。Lispのlambdaとか閉包とか思い出したりしている。実はこの20年は、プログラミング言語論という観点から見ると、基礎概念はそこにあったが、PGが追い付いてこれなかっただけなんじゃないか、と思ったりする。
まあこの会社だと、未だに「C++(←またはC以外の言語名が入る)はプログラムが書けない人のための言語だ」と言ってはばからない人が上司だったりするのでアレなんだけどね。規模に対処するということを軽視した結果が、数々のバグ騒動と品質問題に直結してるのは、ほとんど疑いがない...。
概念的には、「〜という手法が存在するようだ(が俺は関係ないね)」→「〜を実践して効果を実感している」→「〜を言語仕様に取り込んだものを自然と使う」というフローの各段階において、各人の理解度にはギャップがある、ということ。結局、「〜を強く意識しなくても自然と使っていける」、という状態へ辿り着いて初めて凡人にも使いこなせる状態になるわけね。
Rubyでは生成したオブジェクト(インスタンス)のメソッドを書き換えるちう荒技が使えるんだが、ロートルPGから見れば「それを使うなんてとんでもない」てな感じ。感覚的には、多重継承使うな論、と同じ。きっと、これを使うとすっきりモデリングできる事象が存在するんだろうなあ。
Ruby とはちょっと違うのですが、Javaもオブジェクトのメソッドを外部操作できて(Reflection)、これをつかったオブジェクトの挙動の書き換えは、いまやエンタープライズ開発の基本技法になってます(Dependency Injection という技法)
ポイントとしては、コンテナが一貫性のあるルールに基づいて
機能をオブジェクトに注入するために使っているというところ
でしょうか。
Ruby でも同様の概念の機構を作るのに有効に使えると思います。
なるほど。DIは、普通にメソッドを呼び合っていると密結合になりがちなオブジェクトのメソッドを、依存性を外部から注入する(メソッドを書き換えている)という奴ですよね。・・・・概念的にはOOPでいうクラス階層・継承という枠組では、再利用性の高い部品は作れそうにもない(少なくとも凡人には)というところのアンチテーゼなんでしょうかね。
リフレクション?とは違うかもしれないけど、CでライブラリのIO部分を関数ポインタ登録で分離するようなもんでしょうか。