プログラミングをする上で、オブジェクト指向は必須の考え方です。
2070年頃に考え方が提唱され、徐々に浸透してきました。
最近登場してきている言語は、ほぼオブジェクト指向をサポートしています。
ここでは、オブジェクト指向とな何なのかと、良く登場する用語についてザックリ解説したいと思います。
オブジェクト指向とは、「役割」に着目したプログラミング手法
オブジェクト指向が登場する前のプログラムは、直線的に上から下へ処理を流していくだけでした。
但し、プログラムの規模が大きくなる（プログラム行数が多くなる）ケースでは、ダラダラと手順をプログラミングしてしまうと、どの場所に何が書かれているのかが把握できなくなるため、
- プログラム全体の中で共通化できるところは共通化する
- 複雑な処理は小さなかたまりに分割し、プログラムを見やすく作る
ということを意識する必要はありました。
もっとも、当時は大きい規模とおもわれたものでも、今の開発規模よりは小さいため、この方法でも十分通用していたのです。
しかしコンピュータの性能が上がり、大型コンピュータでしか扱えない処理がパソコンで行えるようになったことで、プログラムの開発規模が次第に大掛かりなものに変わっていきました。
その結果、今までの方法では「大規模開発ではプログラムが複雑化してしまい、ある機能を修正しようとした場合、どこに影響があるのかが特定しづらい」という問題が顕著になってきたのです。
そこで登場したのがオブジェクト指向による開発手法です。
オブジェクトとは「物」「実体」「対象」という意味を持つ単語ですが、オブジェクト指向では「役割」として捉えた方が分かりやすいでしょう。
今までの方法では、「機能」という単位でプログラムを作り、それを組み合わせて１つの大きなプログラムを作成していました。
オブジェクト指向では、「機能」の代わりに「役割」という考え方でプログラムの単位を作り、それを組み合わせて１つの大きなプログラムを作成します。
下記の図は自動販売機のプログラム例ですが、「機能」単位でプログラムをまとめるとこの様になりました（人によって機能の捉え方が変わりますので、あくまでも一例です）
尚、薄い緑と薄い青で色分けしていますが、薄い緑は商品に関係するもの、薄い青はお金に関係するものです。
次はオブジェクト指向で考えた場合の例です（これも人によって役割の捉え方が違いますので、あくまでも一例です）。
今回は、処理の流れ全体を「商品管理」と「商品代管理」という役割で分割してみました。
両方の違いが分かりますでしょうか？
オブジェクト指向の場合、「商品管理」「商品代管理」のそれぞれに、監視機能やセンターへの送信機能が含まれています。
ここが大きな違いです。
「役割」単位でプログラムを作るとは、その「役割」を果たすために必要な機能を、すべてそこに集約するということを意味します。
オブジェクト指向の考え方は、私たちの日常そのもの
では、何故「役割」という考え方が登場したのでしょう？
それは、私たちの日常生活がそのままモデルになっているからです。
例えば、あなたが社員旅行の幹事になったと仮定してみましょう。
あなたは、まず他の幹事と力を合わせて、旅行先と日程を調整することになります。
そして旅行先と日程が決まったら、旅行代理店に電話して往復のバスと宿泊先の予約を依頼しますよね。
私たちは、バス会社や宿泊先の予約方法を知りませんし、知る必要もありません。
一方、旅行会社は私たちから細かい指示を受けなくても、 バスと宿泊先の予約方法を熟知していて、 全てやってくれます。
ここでいうと、あなたの役割は宿泊先と日程の調整です。
そして、旅行代理店は、バスト宿泊先の予約になります。
このように、私たちは日常の中で色々な役割をこなし、また色々な役割の人と連携しながら物事を進めている訳です。
この考え方が、まさにオブジェクト指向であり、この考え方をプログラミングに適用すると、きっと分かりやすいプログラムが書けるようになると思いませんか？
「役割」を定義したものがクラス
さて、プログラミングにおいて、この「役割」をどのように表現するのでしょう？
プログラミングにおいては、その「役割」を果たすために必要なデータと、そのデータを処理するプログラムを１つにまとめるという事になります。
大規模なプログラムになるほど、「分かりやすい（人が把握しやすい）単位に分けて処理を考える」ことが非常に重要になります。
そういう意味において、私たちの日常生活に登場する「役割」がプログラミングに応用できることはメリットが大きいです。
先ほど、「役割」に必要なデータと、データを処理するプログラムを１つにまとめると言いましたが、この「役割」のことを「クラス」と呼んでいます。
そして「役割」の中にまとめられたデータのことを「プロパティ」、処理するプログラムのことを「メソッド」と呼んでいます。
つまり、クラスとは「役割」を果たすためプロパティとメソッドを備えたプログラム単位と言えます。
先ほどの旅行代理店で例えると、営業時間や電話番号、所在地などがプロパティ、旅行先予約、代金決済、問合せ受付などがメソッドに相当します。
もし旅行会社の業務をプログラミングで実現するのであれば、このようなプロパティやメソッドを用意することになります。
実際には、オブジェクト指向の難易度は高い
ここまでオブジェクト指向を肯定的に説明してきました。
でも、実際には結構難易度が高い事も事実です。
それは何故か？
旅行代理店の例は、「バスと宿泊施設の予約」という役割が明確だったので分かりやすかったのですが、現実はそう簡単ではありません。
現実社会では、様々な部門で複数の役割を持った人が業務を行っており、細かな部分で入り組んだ構造になっています。
オブジェクト指向は「役割」に必要なデータ（プロパティ）と処理プログラム（メソッド）を集める何時用がありますが、様々なデータが多くの人や部門で共有化されているため、どんなクラスを作り、どのデータをどのクラスに含めるかが非常に悩ましいのです。
例えば、在庫管理を例にした場合、何を役割にすればよいでしょう。
入庫、出庫、発注、受入、支払、発注取り消し、受注取り消し、棚卸、在庫数管理、帳票出力などの業務があるので、これらうまく分類できる役割を考える必要があります。
在庫管理なので安直に「在庫管理クラス」を考えた場合、全てが「在庫管理クラス」に含まれてしまうので、今までの（オブジェクト指向ではない）作り方と変わりません。
ここで、ある人が「入庫クラス」「出庫クラス」「発注クラス」という３つのクラスに振り分けることを考えた場合、共有が必要な「在庫数」はどこのクラスに含めるべきでしょう？
ある人は「入庫クラス」「出庫クラス」を作って、発注と支払いは入庫に関係するから「入庫クラス」に含めようとするかもしれません。
つまり、ある物事を考えた場合、そこから考え出される役割は人によって違ってくるという事です。
クラスは多すぎると管理しずらくなり、少なすぎると１つのクラスが巨大化しすぎるので、ちょうどよい個数を探さなければなりません。
この適切な数というのが曖昧で、さらに人によって役割の考え方も変わるという前提のもとクラス、プロパティ、メソッドを考えていく必要があるため、難易度が高いのです。
まとめ
- オブジェクト指向は「役割」に着目したプログラム手法
- 私たちに身近な「役割」という考え方が、もとになっている
- 「役割」を定義したものを「クラス」と呼ぶ
- クラスの中にまとめられたデータを「プロパティ」と呼ぶ
- クラスの中のデータを処理するプログラムを「メソッド」と呼ぶ
- 実際には、オブジェクト指向の難易度は高い
という事です。