« 工学部の先生による教育問題の見方 | トップページ | 健保組合解散の是非 »

2008年8月19日 (火)

OOPL - 命令型 - 関数型 = ?

この分類をJavaが手近なので当てはめてみる。ServletやActionについてはモジュールだ。一見、ある特定Webアプリケーションに特化したように見えるが、ユーザーに対しては何もしないインフラのみのクラスにfeatureを加えているのは明らかだ。このタイプは実装継承が有効に働く。

では、型と言えるのは何だろう? ...... 思いつかない。

これが、犬猫OO解釈がだめになった理由ではないか? 少なくともJavaで構築するタイプのアプリケーションあるいはサービスにおいてのOOの利用はモジュールの側だからだ。

拡張と特殊化 (L'eclat des jours)

型といえる場合、というもので、私が典型的に思い浮かべるのは、「複素数型」ですかね。『プログラミング言語 C++』で例として取り上げられていたと思います。あるいは、 Ruby ですと、 Numeric 型を継承した Integer 型、 Float 型など。

OO の「クラス」を、ある種の代数的構造として使おうとする場合でしょうね。 C++ での、演算子オーバーロード、 friend 指定 など、こうした方向性を持っていたと思います。

関数型プログラミング言語 Haskell では、

  • 型: 値の集合
  • クラス: 型に対する関数の集合

と、かなり明確な形で、代数的構造を作るための機構が用意されているようです。

この場合、「値の集合」であるところの型というのは、「継承」されたりはしないわけでして、「継承」されるのは、「関数の集合」としての「クラス」だけですね。

こうした風に、 OO の「クラス」を使うというのは、やはり、中途半端な感があるわけでして、 OO 「ならでは」、という感じではないですよね。 OO の機能を使って、関数プログラミングの真似事をしているみたいです。

とすると、やはり、 OO 独自の特徴としましては、

  • オブジェクトが状態を持ち、メソッドの副作用でオブジェクトの状態が変わる
  • オブジェクトの状態を継承できる

といったあたりにあるのであろう、と思うわけでして。俗にいう、「実装の継承」というのは、ほぼ「状態の継承」を含んでいるのではないかと思いますね。

たしかに継承は便利機能に過ぎなくて,本来不要なものかもしれない。でも, 実際すごく便利なんだ。 C++ で継承を避けて合成・包含を優先するように設計を行っていくと,最終的に酷く面倒なことになるケースが多い。継承を避けるのはストイックで安全なやり方かもしれないけれど,なぜ楽にできることを楽にしないのだろうという,妙な矛盾と直面することになる。

継承を禁忌すること (Radium Software)

「悪しき習慣であるが、すごく便利だ」というのは、 OOPL のプログラミング言語としての位置付けを端的に言い表しているのではないでしょうか。論理的な明快さを優先するなら、関数型が勝るはずであるわけでして、 OOPL の存在意義というのは、まさにその悪しき便利機能にあるのではないですかね。

すぐに思い出せるだけでもWadlerとかXiとか、「オブジェクト指向は駄目」と言っている(のを私が聞いたことがある)プログラミング言語研究者は少なくありません。

オブジェクト指向と私 (sumiiの日記)

プログラミング言語のアカデメイアでは、 OOPL はあまり好まれてはいないそうで。

|

« 工学部の先生による教育問題の見方 | トップページ | 健保組合解散の是非 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/23075575

この記事へのトラックバック一覧です: OOPL - 命令型 - 関数型 = ?:

« 工学部の先生による教育問題の見方 | トップページ | 健保組合解散の是非 »