オブジェクト指向

オブジェクト指向とは、オブジェクト・オリエンテッドの訳語であり、プログラミング・パラダイムのひとつである。
ただし、提唱者によれば「『メッセージング主導』とでもしておけばよかった orz」だそうである。現在のようにメジャーな概念になるとは思っておらず、「誰かがもうちょっとマシなネーミングをしてくれるだろう」と思っていたらしい。
「オリエンテッド」は「東方指向」あるいは「東方志向」であり、アレクサンドロス大王の東征に由来し、「オリエンテーション」などの語源となった。アレクサンドロスは西欧の西端であるマケドニアの領主であり、（現在は、「東洋」には分類されない）ギリシャ文化やメソポタミア文化に憧れたらしく、積極的に東方文化を取り入れた（「光は東方にあり」というスローガンが知られている）。その結果としてギリシャ文化が地中海地方からマケドニアに至るギリシャ文化を形成し、ヘレニズム文化圏が構築された。ヘレニズムに関しては、別項に譲る。
そのため、オブジェクト“志向”なのか“指向”なのかについては議論がある。

概要

もともとは C 言語で書かれたシステムが巨大化してくると保守が面倒臭くなって手に負えなくなるので、外側に「オブジェクト指向」という面の皮を被せて見てくれをよくしようという目論見であった。
「皮を被せる」ということは「中身を隠蔽する」ということと同義である。C 言語では複数のデータをまとめて「構造体」としてパッケージングしただけで、それぞれのデータをどう扱うかは、扱う側が弁えていなければならない。そこで「問い合わせ」のレベルでオブジェクト側が区別をして、「どういう問合せに対してはどのデータにどういう処理をして応答を返すか」という話に持ってゆこうという話である。
具体的なレベルで考えるなら立食い蕎麦あたりになって、「券売機でチケットを買って、それを厨房に渡すと、品物が出てくる」というレベルの話であり、「うどん／そば」「大盛／普通盛」「あったかいの／冷たいの／ぶっかけ」「種」というオプションを指定してコンストラクトすると、盆というオブジェクトが出てくる。で、食べ終わった器は C 言語では alloc() されたリソースなわけで、明示的二 free() しないと食器というリソースが尽きてしまうが、Java だと参照カウンタが見張っていてどこからも参照されなくなると回収されてリソースとして再利用される。
したがって、オブジェクト指向言語は店の中から見ればオブジェクト指向だが、客から見ればメッセージ指向である。

オブジェクトとは

「オブジェクト」とは、要するに「もの」「実在（実体）」であり、メッセージングはオブジェクト間の「やりとり」「通信」「相互作用」である。したがって、実在していない（実体のない）オブジェクトにはメッセージは投げられない。したがって、

• 静的な（スタティックな）オブジェクトとして定義するか
• 明示的（つまりnew）または暗示的にコンストラクトされて「参照」と結びつけられるか

蕎麦屋における静的なオブジェクトは椅子とテーブル、お冷や、そば湯、七味唐辛子など、注文(new)しなくても利用できるものであり、注文してから出てくるものはダイナミックなオブジェクトである。
オブジェクトと結びついていない参照にはヌル（null）が入っており、そこにチョッカイを出す（メッセージを投げる）と「ぬるぽ」になっげガッされるのがJavaの（ネット社会での）お約束である。
古くは、日本語では「もの」は「鬼」と書いた。アプリケーションが起動するとそこには「名前空間」が構築され、そのとき名前空間内に棲んでいる鬼が静的なオブジェクトである。これに対して動的なオブジェクトの宣言は「鬼の設計図」みたいなものである。この「鬼の設計図」にマジナイをかける（new する）とオブジェクトが一匹沸いて出るダイナミックなオブジェクトである。
スタティックなオブジェクトは実行環境にただ一つある（同時に一つしかない）ので、いわゆる大域変数などを渡すときには便利（「シングルトン実装」という）であり、数値演算パッケージなどもスタティックなオブジェクトとして実装される。ダイナミックなオブジェクトは new したら new しただけ（リソースが尽きなければ）沸いて出るので、それぞれのオブジェクトはそれぞれ独立に動作する。
オブジェクトとオブジェクトの間では、一方のオブジェクトが他方のオブジェクトにメッセージを投げることで通信し、「で、結局どうなった？」というメッセージを受けることで結果を受けとる。一般的にはスタティックなオブジェクトの場合はメソッド一発で片付くが、ダイナミックなオブジェクトの場合は new するときに引数を渡し、「getなんとか」というメソッドを呼んで結果を得るか、「setなんとか」してから「getなんとか」して結果を受けることになる。
この「setなんとか」「getなんとか」「isなんとか」をいちいち用意するのが面倒臭いからイヤだという人はいるが、職業的な Java プログラマの中には（Ｗeb 系のシステムを開発するさいには、「NetBeans」というものがあり、JSPとセットになって使われる）「いや、それがいい。落ちつく。」という人もいる。Java は応用範囲が広いため、JSP を用いない非・Web 系のJavaプログラマには、これを変態扱いする人もいる。

プログラミング言語

オブジェクト指向型のプログラミング言語は多数あるが、現在システム開発の現場で使われているものとしては Java がある。二十年前だったらオブジェクト指向というプログラミング・パラダイムとしては目新しかったが、現在ではフツーなので Java を使っていても「貧乏人」程度のイメージしかない。なにしろ開発環境（Eclipseなど）と実行環境が無料であり、大抵の用途には用が足りるからである。同時に思ったより遅くないし、実行環境も選ばないし、面倒臭い点としてはファイルの数が増えるのとドキュメントを整理しておかないと同じコードを何度も書くような恥ずかしいことになってしまうことである。　

クラスの設計

具体的な話に落とそうとすると何の話をしているか分からなくなるので抽象化する。とはいえ「象をひっぱる」わけだから引きずられるリスクはあるわけで、アフリカ象ではなくてインド象クラスのおとなしい奴を選ぶことにする。
まず、「長方形」というクラスを考えよう。縦の辺も横の辺も正の整数だとしよう。さらに、対角線の長さも自然数という特殊なやつがいるので、それが十五頭いるとする。 そうすると、こいつらは「縦辺」「横辺」「対角線」という性質を持っているが縦線と横線の長さで決まっちゃうので自由度は２である。こいつらを仮に BR と呼ぶ。
ただし、「３×４」の長方形と「４×３」は同じものなので、BRx.equals(BRy); とかやったときには true が返ってくるような工夫がいる。
でまあ、問題は ３×４＝４×３はいいとして４５×６０なんていうのが一匹混じっていたときにどうするか？という話になる。 そんなわけで、「形が一緒なんだからイコールでいいよね」とか「どうせなら短辺と長辺の比を『アスペクト比』とかいう値を定義してもいいんじゃない？」というので 「isアスペクト比()」なんていうメソッドを考えて、ついでに整列キーにしたらどうじゃろか？ってな話になる。
ここで内情をバラすと、この話の元になったのは古代バビロニア時代の「プリンプトン322」という粘土板に書いてあった十五個の値である。これは1955年以来「なんだかわからん」というので正体不明とされてきたのだが、こうやって「バビロニア長方形」というクラスに押しこんでアスペクト比で整列させてみると、「正方形と黄金長方形」の間に入る原始バビロニア長方形と相似で、２つだけ例外があるというのが分かった。
要するに、「クラスを設計する」というのは「見立て」なのである。能舞台の作りもののように、「それっぽい風情」が出ていて、それぞれ役柄を象徴する面をかけるのがクラス設計だろう。
この点、C 言語は丸出しなので「見立て」が難しい。そこで「オブジェクト指向」という様式ができたのではないだろうか。