オブジェクト指向

プログラミングを行なう時、流れを追って作っていくと簡単に作れるが、後々修正する時に面倒になる。一日の動作に例えると、

起きる⇒飯を食う⇒働く⇒飯を食う⇒働く⇒飯を食う⇒寝る

ここで共通の「飯を食う」がバラバラに書いてあると、ご飯の食べ方を変える（修正する）場合に、３つあるから３つとも書き換えなきゃならない。でも、共通の作業を「関数」として作れば修正は１箇所で済むのだ。

起きる⇒飯を食う⇔働く⇒寝る

多くのプログラムはこういう関数の集合体でできている。

■オブジェクト指向

「飯を食う」時、レストランに行けばすぐに食べられる。ここで、自分で作る人もいるだろうが時間と手間がかかる。ましてや自分で食材を採りに行くなんてことは非効率的だ。レストランで飯を食うにしても、料理人がどこで食材を手に入れ、どうやって調理しているかを知らなくても、お金を出せば料理が出てきて食べられる。どんな人が来ても、お金さえ払えば飯は食えるのだ。社会は個人や団体が役割を分担し成り立っている。たった１人で１から10までやるサバイバル的な生活をしている人は少ないはずだ。
プログラミングも同じように、１から10まで順番に書いたプログラムは非効率的である。関数やクラスに役割を分担させ、どんなプログラムでも引数を出せば結果が出てくるようにし、それが集合していれば大きなことができる。関数やクラスに汎用性を持たせれば、新しくプログラムを作る時に、その関数やクラスについて考える必要がない。主プログラムは「あ〜して、こ〜して」と細かいことを書かなくて済むから、飯を食うときは「飯を食う」と書くだけ。非常にスッキリした分かりやすいプログラムになる。
このように１つの役割を１つの「もの・こと（オブジェクト）」としてとらえ、プログラミングしていく考え方をオブジェクト指向という。

■クラスとインスタンス

１つのラーメンを数人で食べると、人によって食べ方は違うので「勝手にニンニク入れるなよ！」とかケンカになるかもしれないが、１人につき１つのラーメンを出せばケンカにならない（当たり前だけど）。そのラーメンはどんな食べ方をしても個人の自由だ。だけど、作るたびに味が違ってはいけないのでレシピを作る。
プログラムも同じように、１つの関数をいろんなところから呼び出すと「勝手に$aに１足すなよ！」とケンカになるかもしれないが、同じ関数をその動作に応じて作成すればケンカにならない。それがクラスとインスタンスなのである。上の例で言えばレシピがクラス、できたラーメンがインスタンスとなる。
インスタンスはクラスのコピーだが、メモリ上でコピーするだけで、いちいち同じクラスを複数書くわけじゃない。レシピは１つあれば十分で、ラーメンは食べ終われば必要なくなるのだ。

■クラスの継承

料理人はやがてのれん分けされ、自分の店を持つ。自分の店では本店の味を継承しつつ、自分のアレンジを加えて別の味が作れる。クラスも同じようにもとのクラスを継承して別のクラスを作ることができるというメリットがある。