「オブジェクト指向」の黒歴史

no extension

(もちろんタイトルは釣りです)

Qiita で面白い記事を見かけた。

この記事にあるオブジェクト指向の価値を利便性に置くという考え方には激しく同意する。 その上で,私の黒歴史を交えて,戯れ言をいくつか書いてみよう。

「プログラミング」で最初に何を学びましたか?

最近の子らは「プログラミング」で何を学ぶのだろう。

私が学生の頃(昭和時代), FORTRAN の授業で真っ先にやらされたのがフローチャートを書くことだった1。 ちなみに授業の最初のお題は素数を求めるプログラムだった(ありがちw)。

そもそも「コンピュータ」っていうのは,名前の通り,「計算をする機械」なわけですよ。 つまりフローチャートというのは「計算する」ことをモデル化したものなわけ。 だから「計算する」ことに関してはフローチャートで全て表現できる。

そう思ってた時代がありました。

それから,まぁ,紆余曲折あって(バブル最盛期に)某システムハウスに潜り込んだのだが,初仕事の設計書で書かせられたのはフローチャートではなく状態遷移表だった。 むしろ「フローチャートなんか要らん(コードを見れば分かる)」と言われましたよ。 これが「社会の現実」ってやつですね,分かります。

ここで社会に出たての小僧は気づくわけですよ,「コンピュータ」っていうのは「計算 をする機械」ではなく「情報 を処理する機械」なんだということを。 そして少年は「オブジェクト指向」と出会う(笑)

「情報」ってなに?

少なくともノイマン型コンピュータにおいては,基本的に以下の3つの機能しかない。

  • 指定したアドレスから命令をフェッチして計算する
  • 指定したアドレスからデータを読む
  • 指定したアドレスへデータを書く

指定したアドレス(メモリとは限らない)に何があるのか決めるのはコードを書く人間側の責務であり,それを可能とするプログラミング言語であれば「情報を処理する」ことに関しては何でもできる。

じゃあ「情報」ってなに?

「オブジェクト指向」以前の「構造化プログラミング」の時代において,情報とは「データ」と「機能」だった。 しかし「データ」と「機能」だけではコードは簡単に破綻する。 以前に「ハード屋が書く C ソースコードが凄まじかった思い出」という記事を書いたが,これは情報を「データ」と「機能」と考えた場合の極端例と言える。

では「構造化プログラミング」時代のソフトウェア・エンジニアのコードは何故破綻しなかったのか2。 ソフトウェア・エンジニアが暗黙的に考えていたこととはなにか。 その答えのひとつが情報を「オブジェクト」と考える「オブジェクト指向」設計ないしはプログラミングである。

「オブジェクト指向」設計ではオブジェクトを以下の3つの組み合わせと考えた。

  • 名前
  • 状態(属性)
  • 機能(操作,手段)

特に重要なのが「名前」である。 「名前」とは自と他を区別する識別子で,区別することでそこに「関係」が生まれる。

たとえば「犬は動物の一種である」というのは,「犬」と「動物」の関係が「一種である3(is-a)」ことを示す。 C++ や Java では「一種である」という関係を「クラス・オブジェクトの継承」という形で記述するが,継承は「オブジェクト指向」に必須の記述ではない。 Go 言語の構造的部分型(structural subtyping)のような記述だってあるのだ4

つまり「オブジェクト指向」においてはオブジェクトとその関係をモデル化することが重要で,それを記述することができるのであればどんな言語でも構わないのである。

ちなみに「オブジェクト指向」プログラミングはアセンブラや C 言語でも記述できるし実際にそういうプロジェクトに関わったこともある(大昔の話だよ)。 プログラミング言語はプログラミングの手段に過ぎないということだ。

「オブジェクト指向」の先へ

しかし今さらアセンブラや C 言語で「オブジェクト指向」なコードを書こうという人は少ない(いや,ほぼいない?)だろう。 では,当時オブジェクト指向プログラミング言語と呼ばれた C++ や Java によって私達ソフトウェア・エンジニアは幸せになれたのだろうか? 否である!

これは私見だけど,「オブジェクト指向」の恩恵は「オブジェクト指向」で設計・記述できるようになったことではなく「オブジェクト指向」からの派生でコード記述が文芸的5 になり意図や文脈を記述するようになってきたことだと思う。

こうした発展はプログラミング言語のトレンドがオブジェクト指向言語だけではなく関数型言語など複数のパラダイムをブレンドした「マルチパラダイム・プログラミング言語」へシフトしていることからも言えるんじゃないだろうか。 また FOSS が主流となりプログラムコードがエンジニア同士の対話手段として使われるようになったことも影響しているかもしれない6

そういう意味で「オブジェクト指向はこうあるべき」という議論は不毛で非生産的な行為と言える。 私達はもはやその先に足を踏み入れているのだから。

ブックマーク

参考図書

photo
あなたはコンピュータを理解していますか? 10年後、20年後まで必ず役立つ根っこの部分がきっちりわかる! (サイエンス・アイ新書)
梅津 信幸
ソフトバンク クリエイティブ 2007-03-16
評価

あなたはネットワークを理解していますか? インターネット時代に欠かせない根っこの知識が確実に身につく! (サイエンス・アイ新書) 痛快!コンピュータ学 (集英社文庫) コンピュータのしくみを理解するための10章 カラー図解でわかる通信のしくみ あなたはインターネット&モバイル通信をどこまで理解していますか? (サイエンス・アイ新書) 図解でかんたんアルゴリズム 情報処理のかなめとなる考え方が手に取るようにわかる! (サイエンス・アイ新書) コンピュータはなぜ動くのか~知っておきたいハードウエア&ソフトウエアの基礎知識~ コンピューター&テクノロジー解体新書 情報はなぜビットなのか 知っておきたいコンピュータと情報処理の基礎知識 史上最強カラー図解 プロが教えるパソコンのすべてがわかる本 文庫 思考する機械コンピュータ (草思社文庫)

2002年に技術評論社から出た同名タイトルのリニューアルらしい。

reviewed by Spiegel on 2017-11-24 (powered by G-Tools)

photo
数学ガール/乱択アルゴリズム
結城 浩
SBクリエイティブ株式会社 2014-02-14
評価

数学ガール/ゲーデルの不完全性定理 数学ガール/フェルマーの最終定理 数学ガール/ガロア理論 数学ガール 数学ガールの秘密ノート/式とグラフ

工学ガール,リサちゃん登場!

reviewed by Spiegel on 2015/04/19 (powered by G-Tools)


  1. 今どきの子は知らないかも知れないので念のために解説すると,「フローチャート」というのはコンピュータの処理の流れ(工程)を図式した一種のモデリング言語と思っていただいて構わない。 [return]
  2. いや「動かないコンピュータ」なんてザラにあったけど。むしろ今も見かけるけど(笑) [return]
  3. ちなみに「A は B の一種である」という関係を「汎化(または特化)」と言う。 “A is a B” と当て嵌めて考えれば分かりやすいだろう。 [return]
  4. むしろ継承にこだわって菱形継承のような弱点や例外処理のような歪な構造を生み出したことは初期のオブジェクト指向プログラミング言語の黒歴史と言えるだろう。 [return]
  5. これはいわゆる「文芸的プログラミング」とは意味が異なる。紛らわしくてゴメンペコン。 [return]
  6. まさしく著作権による知的独占からの解放がもたらした好例のひとつですな。 [return]