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 はあまり好まれてはいないそうで。

工学部の先生による教育問題の見方

学力低下は錯覚である 著者：神永 正博 販売元：森北出版 Amazon.co.jpで詳細を確認する

工学部の先生が、ゆとり教育、学力低下、理工系離れ、文系理系の待遇差について論じた本。出版元が森北出版なのも異色な感じですね。

この先生のお考えが、私が漠然と考えていたことと、ほぼ一致しているのが驚きでした。統計データを引きつつ、以下のような見解を示されています。

• いわゆる「ゆとり教育の弊害」は、それを裏付ける証拠がない。
• 「分数のできない大学生」など、大学生の学力が低下しているのは事実。しかし、少子化の進行にともない、18歳人口が急速に減少するなかで、大学の定員はむしろ増加しており、以前なら大学に入学できなかった層が入学していることで説明できる。
• 「理工系」離れが言われているが、現実に起きているのは、「工学部離れ」であり、理系志望の人間自体は増えてもいないが、減ってもいない。理、医薬歯系へとシフトしている。

といったあたりは、文部科学省の統計データを眺めたりして、そういった傾向が見えないか、などと私も考えていました。

一方、

• 文系の方が理工系より優遇されている、というが、データからみて、そのようなことはない。

というのは、少々意外な話でしたね。世間に流布する俗説というのはあてにならないものです。

この本の一番最後に、義務教育課程に対する提言がなされているのですが、この点に関しても全く同感です。国語・英語・数学の教科を徹底的にやるべき、とのご意見です。

筆者は、義務教育段階では、基礎教科を、時間をかけて徹底的に学ばせるべきだと思っている。学習には個人差があるので、なかなかわからない子もいるだろう。しかし、わからないからといってここで学び損ねると、後で取り返すのに大変な苦労をしなくてはならない。

【略】

なにがなんでも身につけてもらわなければならないからこそ義務教育なのである。

「詰込み教育」のアンチテーゼとしての「ゆとり教育」であれば、あれもこれもと広く浅くやるのではなく、基礎を徹底してやるのが本来の姿ではないか、と思うのですけどね。

正規化は正しくない、かもしれない

「ノーマライゼーションはノーマルじゃない」の方が語呂が良いですね。

Never, never should you normalize a database out of some vague sense of duty to the ghosts of Boyce-Codd. Normalization is not magical fairy dust you sprinkle over your database to cure all ills; it often creates as many problems as it solves.

Maybe Normalizing Isn't Normal (Coding Horror)

データベースの正規化は、データベースの非正規化と同じくらいには、問題を引き起こすので、無分別に行なうべきではない、という論旨のようです。データーベースの正規化は、クエリのパフォーマンスを低下させ、理解しやすさを損ね、データベースを使いにくくすると。

私も同感です。何であれ、設計というのは、形而上学的に正しい解を求める過程ではなく、目的に手段を適合させる過程であると思います。データベース設計においても、ユーザが何を求めているのか、ユーザにどのような価値を提供しようとしているのかを、よくよく考えて行なうべきでしょう。自動的に解が見つかることはないでしょうね。

以下に、コメント欄を含めた、まとめがあります。

The Mother of All Database Normalization Debates on Coding Horror (High Scalability)

いくつか気に入ったものを意訳してみます：

Normalization is about optimizing large numbers of small CrUD operations, and retrieving small sets of data in order to support those crud operations.

．．．

Denormalization is about optimizing retrieval of large sets of data. Choosing an efficient database design is about understanding which of those operations is more important. (RevMike)

正規化は、大量の小さな挿入・更新・削除操作を行なう場合に使う。非正規化は、巨大なデータを取り出す場合に使う。データベース設計を効果的に行なうには、どういった操作が重要なのかを理解しなくてはならない。

Is my Site OLTP? If the answer is yes then Normalize. Is my site OLAP? If the answer is yes then De-Normalize! (WeAreJimbo)

OLTPなら正規化、OLAPなら非正規化が答えだ。

Be careful not to confuse a denormalised database with a non-normalised database. The former exists because a previously normailsed database needed to be 'optimised' in some way. The latter exists because it was 'designed' that way from scratch. The difference is subtle, but important. (Bob)

非正規化（denormalised database）と、無正規形（non-normalised database）を混同しないように。前者は既に正規化されたデータベースを「最適化」する。後者は初めからそのように「デザイン」される。違いは微妙だが、重要だ。

検証と証明

もし我々の考えている定理が、すべての数について真であることを示すかわりに、たとえば ６ なる数について真だということだけを示したいとすれば、段々になって流れている三段論法の滝のうちから最初の五つだけを証明すれば十分である。 ．．． もっと大きい数についてならば、もっとたくさんとらなければならない。しかしその数がどんなに大きくても、いつでも我々はいつかはそれに到達し得るから、それで分析的検証が可能である。

しかしながら、こうしてどこまで行っても、我々は決してすべての数に適用をみるような一般的な定理までにのぼることはできまい。 ．．． 形式論理だけに頼っている分析論者の忍耐によっては、いつまでたっても満たすことのできない深淵をとび越さなければならない。

ポアンカレ著, 河野伊三郎訳, 『科学と仮説』, 岩波文庫, 1959, p32-33

結局のところ、計算機プログラムを計算機上でいくら実行し、その結果が正しいことを 検証 したところで、そのプログラムが正しいことの 証明 とはならないでしょうね。現実の計算機は、有限のリソースによって制約されますから、計算機プログラムの取りうる状態は有限であるとはいえるのでしょうが、しばしば、全てを検証するには一万年あっても足りないというような大きさであったりします。

チューリング・マシンのような、概念上の計算機は、無限のリソースを持っているわけですが、計算機プログラムも概念的には、無限の状態を取りうるものであると、少なくとも、アルゴリズムの設計段階では考えるものでしょう。この段階で計算機プログラムの取りうる無限の状態に対して、計算機プログラムが正しいことを証明できなければ、計算機プログラムの正しさを保証するチャンスはないのかもしれませんね。

概念上、計算機プログラムの正しさを証明することができたからといって、現実の計算機プログラムの正しさまで保証されるわけではないわけですが。概念上、正しくない計算機プログラムは、現実にも正しくない、ということはいえますね。

計算機プログラムの正しさというのは、それが、現実に計算機上で実行される前には既に決まっていて、 その後、いくら計算機上で実行し検証したところで保証できないものである といえるのではないでしょうかね。

フローチャート不要論

を主張する人の、フローチャートの定義がいまいちよくわからなかったりしますが。

フローチャートというのは、状態遷移図の一種ですよね。この場合、プログラムカウンタ、あるいは、それを抽象化したものが状態変数になっていて、現在実行中のプログラムの「位置」が代わるごとに、状態が遷移していく様子を図式化したものだと思います。

フローチャートというのは、バッチ入力のコンピュータ・プログラムを記述するために、状態遷移図を「カスタマイズ」したのでしょうね。プローチャートと一言にいっても、実際には色々な形式があるようですが、基本的には、バッチ型の単純な逐次実行で行なわれる処理を記述するものだと思います。

フローチャートというのが、オンラインが主流の現在では、時代おくれなのは確かでしょうね。結局、イベント駆動型の非同期処理やら、並列処理やらを記述する必要性が出てきて、再び「ただの」状態遷移図へとかえったとみるべきかと。

とはいえ、バッチ的な処理がなくなったわけでもありませんので、そうした場合には、フローチャートは使いますけどね。フローチャート的な状態遷移図といったほうが良いかもしれませんけど。一種類のボックスと線しかなかったりしますから。

入力データチェックのシーケンスを書くことが、一番多いですかね。 x ＜ a なら、 エラーXXX で、そうでなければ、 y < b をチェックして、等と延々と連なっているような処理。こうした処理では、チェックの順番が意味を持つことは多いですから、フローチャートですと表現しやすいですね。

ちなみに、状態遷移図といいますか、状態マシン／オートマトンは、近年、なかなか面白い展開を見せていて、モデル検査という分野に発展しているようです。２つ以上の異なるプロセスを表現したオートマトンを、「掛け合わせ」て、ひとつの巨大なオートマトンを作り、この全ての状態遷移をチェックすることで、デッドロック等の並列処理のバグを見つけ出そうというもの。2007年の ACM チューリング賞は、この分野の研究者が受賞していますね。

---

SPINモデル検査―検証モデリング技法 著者：中島 震 販売元：近代科学社 Amazon.co.jpで詳細を確認する