オブジェクト指向

オブジェクト指向(object oriented)とは、1980年代以降ずっと主流を占めているプログラミングパラダイムである。

概要

オブジェクト指向とは、手続きをオブジェクト(対象)を単位として考えることによって、「対象を(が)〜する」という人間の思考に近い形でプログラミングしようとするプログラミングパラダイムである。

C言語を代表格とする手続き型言語の欠点を修正するような形で1980年代に普及した。C言語との互換性を保ちつつオブジェクト指向を採り入れたC++はその先鋒にあたるが、元祖ではない。普及以降、関数型プログラミング派からは異論があるかもしれないが、2021年現在においても主流のプログラミングパラダイムである。

クラス

オブジェクト指向プログラミングで中核をなすのが型理論に基づくクラスの概念である。オブジェクト指向の三大要素とされるカプセル化・継承・多態性もクラスの性質に関するものである。

クラスはオブジェクトが保持するデータ構造とそれに対する操作をまとめたもので、共通する性質を持つオブジェクトをひとまとめにする働きがあるのだが、話すと長くなるので詳しく知りたい人向けには後述することにする。

細かいことを言えば、クラス構造をプログラム実行時に変更できない言語(クラスベース)と、変更を行える言語(プロトタイプベース)が存在するが、プログラミング初級者までは気にしなくてよい。中には、クラスというものを排除してオブジェクト指向を実現した言語(SelfやLENSなど）も存在するが、プログラミング言語マニアでもない限り忘れてよい。

明確な定義はない?

主流かつ人気のプログラミングパラダイムであり、大抵の実用的プログラミング言語で採用されているが、各言語で実装される時に言語毎にアレンジを受けており、アレンジされたそれぞれがオブジェクト指向を名乗っている。

プログラミング解説書も売り込みのために「オブジェクト指向で〜」とキャッチコピーやタイトルに入れることが多々あり、各言語のオブジェクト指向はさらに各解説書著者による解釈を受けている。つまり、オリジナルとされる定義や上記三大要素のように一定の支持を得ている定義もあるにはあるが、オブジェクト指向に決定的な定義はなく、著者の数だけ「オブジェクト指向」の定義があると言えるかもしれない。なんでもかんでもオブジェクト指向という風潮だと言えなくもない。

だがちょっと待って欲しい。言語や書籍によるオブジェクト指向礼賛の流れに感化されて、「オブジェクト指向にすれば何でも解決する」と神格化してしまってはいないだろうか。オブジェクト指向の定義すら確固としたものは存在しないのに、「何でも解決できるオブジェクト指向の定義」を探そうとして、無意識に「オブジェクト指向ならうまくいくはずだから、うまくいかないのはオブジェクト指向を理解できていないせいだ」のような逆転的論理に陥ってはいないだろうか。

詳細の部では最大公約数的なものを目指して記述するつもりだが、読んで俺の知ってるオブジェクト指向と違うと思ったのならお互いにそういうことなのだろう。異論は認める。

関連項目

• オブジェクト
• インスタンス
• クラス / 型付け
• モジュール
• インターフェイス(ダイヤモンド継承)
• メソッド / プロパティ
• ポリモーフィズム
• プログラミングパラダイム
  • 手続き型プログラミング
  • 関数型プログラミング
• C++ / Java
• プログラミング関連用語の一覧

---

もっと具体的に知りたい人向け

以下ではプログラミング未経験者でも読めるように、出来るだけ特定のプログラミング言語に依存しない記述を試みるが、長いので下記を参考に希望のレベルまで読み進めること。

• オブジェクト指向の雰囲気とクラスについて具体的に知りたい → 詳細まで
• 三大要素とされるカプセル化・継承・多態性の説明も欲しい→ 利点まで
• オブジェクト指向を越えたい → 難点まで読んだ後、自力で何とかしよう

プログラミングでは実際にやってみないと実感がわかない話はたくさんある。読んでわからないのであれば、一度Javaあたりでオブジェクトやクラスを定義したプログラミングを書いてみるしかないかもしれない。なお、不備に見えるものでも説明を簡略化するためあえてそうしてあるところもある。

詳細

例示のために特殊な状況を設定する。

あなた(プログラマー)が動物園の飼育員(コンピューター)の監督に就任したとしよう。あなたは飼育員に対して飼育マニュアル(プログラム)を通じて指示することしか出来ず、自ら動物と触れ合うことは出来ない。

説明のための例示であり、実在の動物園・飼育員・監督・動物等及びその動作とは一切関係ない。異論は認めない。

Before

この動物園にはA, B, Cという名前の3頭の虎がいる。

あなたは思考を放棄してすべての手順(手続き)を逐一書き出すことにした。

飼育員の業務

虎Aに対し肉10kgを用意する。
虎A用の肉10kgを1kgごとに切り分ける。
虎Aの檻に切り分けた肉を置いてくる。
虎Aは満腹になる。
虎Bに対し肉10kgを用意する。
虎B用の肉10kgを1kgごとに切り分ける。
虎Bの檻に切り分けた肉を置いてくる。
虎Bは満腹になる。
虎Cに対し肉10kgを用意する。
虎用の肉10kgを1kgごとに切り分ける。
虎Cの檻に切り分けた肉を置いてくる。
虎Cは満腹になる。

上記でもゲシュタルト崩壊して十分読みづらいが、さらに虎の数が増えた時に収拾がつかなくなるのは、想像に難くない。間違いにも気づきにくくなる。「虎C」と書くところを「虎」としてしまっていることに初見で気づいた人はどれくらいいただろうか。

After

オブジェクト指向を導入すると、上記のマニュアルは以下のようになる。

虎

虎は空腹になったり満腹になったりする。

餌のやり方

虎に対し肉10kgを用意する。
虎用の肉10kgを1kgごとに切り分ける。
虎の檻に切り分けた肉を置いてくる。
虎は満腹になる。

飼育員の業務

虎A, B, Cに餌をやる。

なんということでしょう

業務内容をA, B, Cという対象(object)を単位として整理するという方針に従えば(oriented)、A, B, Cは「虎」に分類(classify)されてひと括りに扱うことができるようになり、 飼育員のすることは変わっていないのにマニュアルの見通しが良くなったのである。

これなら虎の数が少々増えても読みづらくはならない。また、現実の監督が飼育員に指示する時もBeforeよりAfterのやり方になるであろうことから、より人間の考え方に近づいているということもおわかりいただけただろうか。

用語解説

• オブジェクト(object): 操作対象のこと。上記の例では虎A, B, Cが該当する。
• クラス(class): 上記でいう「虎」が該当する。分類という意味で学校とは関係ない。
• インスタンス(instance): 虎A, B, Cそれぞれはオブジェクト(対象)なのだが、「虎」という分類の具体例ということで「虎」クラスのインスタンス(事例)という呼び方もする。
• メソッド(method): 上記の例では「餌のやり方」の部分が「虎」クラスのメソッド(方法)である。クラスに分類される対象に対して可能な操作を記している。
• プロパティ(property): クラスに分類される対象の状態を記録する。上記の例では「空腹・満腹」という部分が「虎」のプロパティに該当する。プログラミング言語によってメンバ(member)、フィールド(field)、アトリビュート(attribute)など呼び方がバラバラだが、基本理念は共通である。

オブジェクトについて

オブジェクトには「対象」以外に「物体」という訳語もあるが、スレッドやHTTP接続、果ては関数など形のないものまでオブジェクト(対象)化できるので、オブジェクト = 物体 という考え方に囚われるとよろしくない。

さらに厳密に言うと、オブジェクトは対象の状態を記録したプロパティを束ねたデータの集合体であり対象そのものではない。冷静に考えれば虎「A, B, C」は、それぞれにつけられた名前であって虎そのものではないのだから当然なのであるが、これを忘れると後で虎が異次元空間に消えたり、何もないところから突然現れたりすることになる。

利点

柔軟性

後から虎の餌用の肉を1kgではなく0.5kgごとに切り分けなければならないことが判明したとしよう。オブジェクト指向導入前であれば虎A, B, Cのそれぞれについて全3ヶ所の変更が必要であったが、オブジェクト指向導入後であれば「餌のやり方」の項を1ヶ所変更するだけで済む。

虎Dが増えたとしても、オブジェクト指向なら「虎A, B, C」を「虎A, B, C, D」とするだけである。

このようにオブジェクト指向が導入されれば状況の変更にも柔軟に対応できるようになるのである。

部品化

例えば上記の「虎」の章の部分の執筆を部下に任せることができる(部下がいるほど偉ければだが)。

一旦任せてしまえば、たとえば先述の肉の切り分け単位が変わったケースでもあなた自身が対応をする必要はない。

また、任された部下が、虎のプロパティに空腹か満腹かを記録する代わりに、その日に食べた肉の量を記録して、10kgに満たなければ空腹であると判断するようにしても、あなた自身はそれを気にする必要はない。

このような状態を、内部実装がカプセルの中に隠蔽されると見立ててカプセル化と呼ぶ。

カプセル化により、あなた自身は「虎」の細かいことは気にせずに「飼育員の業務」の章の執筆に専念することができる。また、「虎」の章だけを部品のように「動物園」から持ち出して、「サーカス」や「アフリカの動物保護施設」のような別の施設で使ってマニュアル執筆の手間を大幅に省くことも夢ではない。

共通化

虎DではなくサイE, Fが増えたとしよう。以下のような対応が可能である。

動物

動物は空腹になったり満腹になったりする。

餌のやり方

動物に対し餌を用意する。
動物の檻に用意した餌を置いてくる。
動物は満腹になる。

虎

虎は動物である。

餌の用意

虎に対し肉10kgを用意する。
虎用の肉10kgを1kgごとに切り分ける。

サイ

サイは動物である。

餌の用意

サイに対し草を10kg用意する。(切り分けなくて良い)

飼育員の業務

A, B, Cは虎である。
E, Fはサイである。

動物A, B, C, E, Fに餌をやる。

「虎」と「サイ」の共通点である「動物」という性質(分類)を記述することにより、虎とサイについては相違点である餌の用意方法だけを記述すれば済むようになっている。

そして、餌をやる時も「虎」と「サイ」について別々に記述せず「動物」とひと括りにして餌をやることができるのだ。

用語解説2

• サブクラス(subclass): 分類上、あるクラス(分類)をさらに細かく分類した下位の分類にあたるクラスのこと。上記では「虎」「サイ」が「動物」のサブクラスに当たる。派生クラスという呼び方もある。
• スーパークラス(super class): サブクラスの反対。上記では「動物」が「虎」「サイ」のスーパークラスに当たる。基底クラスという呼び方もある。スーパーとついているが、サブクラスの方が多機能である。
• 継承(inheritance): サブクラスはスーパークラスの性質を継承しているという、オブジェクト指向や型付けにおけるルール。上記では「虎」「サイ」が「動物」(の一種)であると宣言することで実現している。
• 多態性(polymorphism): 同じクラスなのに違う振る舞いをすること。上記ではA, B, Cは虎でE, Fはサイだが全て動物であるという点では共通している。「餌をやる」という操作に対して、動物であるという点ではA, B, C, E, Fで共通しているにもかかわらず、A, B, Cには「虎の餌のやり方」が実施され、E, Fには「サイの餌のやり方」が実施される。

リスコフの置換原則

サブクラスのインスタンスは必ずスーパークラスの性質を備えているべきであり、スーパークラスのインスタンスと置き換えて使用することができるという「継承」の原則論。

上記でいうなら「動物X」と書かれているところがあれば、「虎A」や「サイF」で置き換えてもマニュアルとして意味不明や実施不可能にならないということ。

これを満たさない継承はおそらくまともに動作しないのでやってはならない。

難点

プログラミングミスの話をしよう。

プログラミングはコーディングよりもデバッグの方が大変だという話もあるくらいで、ミスによるバグをなくすというのもプログラミング言語やパラダイムの大事な役割である。オブジェクト指向により手続き型プログラミングと呼ばれる旧来のスタイルよりもバグは大幅に減ったが、それでも問題点を完全になくすことはできなかった。概要で述べたようにオブジェクト指向は全てを解決する銀の弾丸ではない。

以下ではオブジェクト指向が批判される原因となるミスについて、上記の例を引き継いで解説しようと思う。単純化して説明するので「そんなミスする奴いねーよ、バーカ」とか思ってしまうかもしれない。しかし、日々繰り返したり、他のことと組み合わさって複雑になったりすると実際に起きてしまうのだ。

状態変化

以下のルールを追加する。

虎は、満腹時に餌を与えると過食により死亡する。

なお、虎が死亡するとあなたは監督責任を問われてクビになる(プログラムの異常終了)。

---

動物園は発展し、あなたは出世して部下に各動物のマニュアル作成を任せ、自身は「飼育員の業務」の章の執筆に専念できるようになった。そんな折、「猛獣ショーをやるぞ」という園長の掛け声のもと手順書が以下のように変更された。単純化のためサイは来なかったものとする。

飼育員の業務

虎Cを猛獣ショーに出演させる。
虎A, B, Cに餌をやる。

ところが、猛獣ショー開演当日の閉園後、虎Cが死亡したという報告が届き、あなたはクビになった。

どうしてこうなった。

実は部下に任せていた「虎」の章は以下のようになっていたのだ。

虎

虎は空腹になったり満腹になったりする。
虎は、満腹時に餌を与えると過食により死亡する。

餌のやり方

虎に対し肉10kgを用意する。
虎用の肉10kgを1kgごとに切り分ける。
虎の檻に切り分けた肉を置いてくる。
虎は満腹になる。

猛獣ショー

虎が芸をするごとに褒美として肉を1kg与える。
虎が満腹になったら終了。

猛獣ショーで虎Cはご褒美をもらって満腹になっており、この状態で虎A, Bと共に餌を与えられたため過食により死亡したのだ。

このような不幸な事故が起こった原因としては色々考えられるが、一つはマニュアルにおいて虎Cと書かれているだけでは虎Cが空腹なのか満腹なのかわからないということが挙げられる。つまり虎Cというオブジェクトに空腹という状態と満腹という状態両方が存在しうることが問題なのである。

またカプセル化により「猛獣ショー」のメソッドの中身を意識しなくなったことも原因の一つといえるかもしれない。

この問題を回避する方法は一通りではないのと、方法(参照透過)によっては空腹な虎が異次元空間に消えたりするのでここではこれ以上深入りしない。

オブジェクト指向ではオブジェクトの状態が変化していくことが前提なので、参照透過とは相性が悪いとされている。

不適切な抽象化

抽象化・共通化は利点であるが、共通化した部分に個別に変更する部分が生じた場合、また非共通化することになる。

サイが登場した例に戻って説明する:

虎は肉食獣なので逃走のリスクを下げるため、虎の檻だけ扉を二重にしたくなったとする。檻の出入りは「動物」のメソッドで共通化しているので、虎の檻の出入りの手順だけを変更しようとすると、せっかく共通化した「檻の出入り」の部分を「虎」と「サイ」で別々に書き直さなければならない。別々に書いてあれば「虎」の変更だけで済んだのに、「動物」「虎」「サイ」の3ヶ所に変更が生じてしまう。

継承によるプログラムの部品化はオブジェクト指向の特色とされている。確かに、各プログラミング言語の標準ライブラリレベルで十分な時間と人手をかけて検討されテストされた継承であれば、オブジェクト指向の利益を最大限に享受できるだろう。しかし、末端のプログラマーがその場の思いつきで共通部品化したものについては継承により予期せぬ不具合を引き起こすと言われており、言語仕様上は継承をサポートしていても積極的に継承を利用することは勧めていない場合もある。

おまけ: 宣言型プログラミング

状態変化による悲劇を避ける方法の一つに、状態変化を禁止してイミュータブルとし関数型言語による宣言型プログラミングを行うという方法がある。

→ 宣言型プログラミング