オブジェクト指向

オブジェクト指向とは、プログラムひいてはシステムにおける構成要素を
オブジェクトとして捉える概念である。

プログラミングにおけるオブジェクト指向

オブジェクト指向におけるプログラミングとは特定のデータ構造と振る舞いを持つものを全て物体(オブジェクト)として捉える概念である。

オブジェクト指向では、システム上における、構成要素を分析し、その特徴をまとめてクラスとして定義する。プログラム実行時にクラスの中身としてのデータ群を具体的に決定し、メモリ上にそのデータ群をまとめて配置した塊をオブジェクトと呼ぶ。
クラスにはそのオブジェクトが、どのような内部状態を持つか、どのような操作でどのように内部状態を変化させるべきかを記述する。クラスの構造がプログラム実行前に静的に決まって変更できない言語と、実行時であってもクラスの構造の変更を行える言語が存在する。

各オブジェクトが作用しあって、その内部状態を互いに変化させながら処理が進行するようなプログラムを作ることがオブジェクト指向プログラミングである。オブジェクト指向言語と呼ばれる言語を使用したとしても、必ずしもオブジェクト指向プログラミングとなるわけではない。

オブジェクト指向プログラミングにおいて、クラスの概念を持つ言語でプログラミングする場合がほとんどである。しかしクラスというものを排除してオブジェクト指向を実現した言語(SelfやLENSなど）も存在する。

三大要素

カプセル化

オブジェクト内のデータを隠蔽することにより「振る舞い」のみに意識させるために行う。

継承（インヘリタンス）

対象のオブジェクトの機能を引き継ぐことを指す。

多態性（ポリモーフィズム）

オブジェクトの詳細な実装が異なっていたたとしても共通した呼び出しで利用することが出来る

ゆっくり編集していってね！！！ 編集者の方へ:2021/4/30 23:59頃の終了を目指し作業しております。 ゆっくり編集していった結果が編集競合にならない様にご協力お願いします。

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

概要

上の概要と統合予定あり。

関数型プログラミング派からは異論があるかもしれないが、2021年現在においても主流のプログラミングパラダイムであり、大抵の実用的プログラミング言語には採り入れられている。

プログラミング解説書も売り込みのために「オブジェクト指向で〜」とタイトルに入れることが多々あり、著者の数だけ「オブジェクト指向」の定義があると言えるかもしれない。以下では最大公約数的なものを目指して記述するつもりだが、読んで俺の知ってるオブジェクト指向と違うと思ったのならお互いにそういうことなのだろう。異論は認める。

以下ではプログラミング未経験者でも読めるように出来るだけ特定のプログラミング言語に依存しない記述を試みるが、プログラミングでは実際にやってみないと実感がわかない話はたくさんある。読んでわからないのであれば、一度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は「虎」に分類(classification)されてひと括りに扱うことができるようになり、 飼育員のすることは変わっていないのにマニュアルの見通しが良くなったのである。

これなら虎の数が少々増えても読みづらくはならない。また、現実の監督が飼育員に指示する時も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に満たなければ空腹であると判断するようにしても、あなた自身はそれを気にする必要はない。

このことにより、あなた自身は「虎」の細かいことは気にせずに「飼育員の業務」の章の執筆に専念することができる。

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

共通化

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

動物

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

餌のやり方

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

虎

虎は動物である。

餌の用意

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

サイ

サイは動物である。

餌の用意

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

飼育員の業務

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

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

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

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

用語解説2

• スーパークラス(super class): 分類上上位に来るクラスのこと。上記では「動物」が「虎」「サイ」のスーパークラスに当たる。基底クラスという呼び方もある。スーパーとついているが、サブクラスの方が多機能である。
• サブクラス(subclass): スーパークラスの反対。上記では「虎」「サイ」が「動物」のサブクラスに当たる。派生クラスという呼び方もある。
• 継承(inheritance): サブクラスはスーパークラスの性質を継承しているということ。上記では「虎」「サイ」が「動物」であると宣言することで実現している。
• 多態性(polymorphism): インスタンス毎に違う振る舞いをすること。上記ではA, B, C, E, Fは動物でもあるが、「餌をやる」という操作に対して、A, B, Cには「虎の餌のやり方」が実施され、E, Fには「サイの餌のやり方」が実施される。

リスコフの置換原則

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

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

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

弊害

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

プログラミングにおいては便利に書けるというのも大事なことだが、ミスによるバグをなくすというのも大事な話である。プログラミングで大変なのはプログラムを書く工程ではなく、バグを探すデバッグ工程であるという話もあるくらいである。

手続き型プログラミングと呼ばれる旧来のスタイルよりも、ミスは減ったがそれでもプログラミングにおける問題点を完全になくすことはできなかった。

以下ではそういったことを上記の例を引き継いで解説しようと思う。

別のところでも書いたが、単純化して説明するので「そんなミスする奴いねーよ、バーカ」とか思ってしまうかもしれない。しかし、日々繰り返したり、他のことと組み合わさって複雑になったりすると実際に起きてしまうのだ。

状態変化

なお、以下では虎が死亡するが、非実在虎であり動物虐待でもなければ虐待を奨励するものでもない。異論は認めない。

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

虎は満腹時に餌を食べると死亡する。
あなたは監督責任を問われてクビになる(プログラムの異常終了)。

動物園は発展し、あなたは出世して部下に各動物のマニュアル作成を任せるようになった。そんな折、手順書が以下のように変更された。

どうしてこうなった

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

不適切な抽象化

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

オマケ: 宣言型プログラミング

関数型プログラミングでは宣言型プログラミングという、ものごとの関係性を「宣言」する形でプログラミングするスタイルが奨励されている。上記の例にあわせて書くと以下のような雰囲気になる。

関連項目

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