プログラム言語をつつく3－オブジェクト指向プログラミング。生産性のあるサブルーチン。
さて、今回は前回の予告どおりオブジェクト指向プログラミングをつつくピヨ。オブジェクト指向って難しいというイメージがあるけど、そんなこと無いピヨ。難しく感じるのは、オブジェクト指向分析、オブジェクト指向プログラミング、オブジェクト指向設計を混合して書いてある書籍やホームページが多いからと言う理由と、オブジェクト指向はあくまでも考え方だから言語設計者毎に差異があるからだよ。
ではオブジェクト指向プログラミングの基礎をつつこう。オブジェクト指向には三つの要素があるピヨ。カプセル化、継承、多態性だよ。また三つ？人間って三つの考えが好きだね。何だか難しそうだけど内容はそんなこと無いよ。名前が難しそうだからそう思うだけだよ。だから肩の力を抜いて一緒に羽ばたこう。
じゃあ最初はカプセル化をつつこう。カプセル化って何だろう？初心者の方は連想できないと思う。ウルトラマンのカプセル怪獣？お薬？閉じ込めるの？・・・そんなわけが分からない事しか思い浮かばないよ。だから名前を気にしちゃだめピヨ。構造化プログラミングを思い出そう。もし構造化プログラミングが分からない人は冒頭近くの「前回」のリンク先を読んでから戻ってきてね。そのまま帰っちゃいやよ。
ここを読んでいると言う事は構造化プログラミングはバッチリだよね。構造化プログラミングでサブルーチン化が重要だと言う事は分かってもらえたと思う。その考えをさらに発展し、プログラムが扱うデータも外部から見えなくするのがカプセル化なんだ。初心者の方はここであれ？となると思う。「データって何？データはサブルーチン化していないの？」ってね。データと言うのは変数とかの事で、実のところ当時1960年代はそうだったんだ。変数はどこからでも見えるし、外部から買い変え放題でプログラムがよくバグっていたんだ。だからプログラムが持つデータの「変数」を隠蔽しようというのがカプセル化って言う事なんだ。思ったより簡単でしょう？プログラミングの初心者はぴんと来ないかもしれないから実例を、プログラム言語ごと記事で書いておくピヨ。プログラム言語ごとに少しずつ違うからね。今の所は変数はなるべく隠蔽した方がいいと覚えるだけでいいピヨ。素直さが肝心だよ。
次は継承をつつこう。継承？これまた難しい単語だねぇ。名前だけで嫌になるピヨ。だけどこれも案外簡単だから頭を白紙にして聞いてね。継承とはコードの重複をなるべく無くすためのものなんだ。プログラムは結構似た処理を書くことが多いんだ。じゃあ、どうやってその重複を防ぐのかと、当時の偉い人たちが頭を悩ました結果コードを引き継げばいい事を思いついたんだ。それが継承ピヨ。親から子へ遺伝子を受け継ぐってわけさ。
初心者の方はコードの重複が如何にバグを生むかぴんとこないと思う。だけどコードの重複はバグの元なんだ。何でかって？コードがほとんど同じだったら打つのが面倒だし、開発の効率性を高めようと思えば、オブジェクト指向を知らない大概の人はプログラムをコピぺすると思う。だけど、後でソフトの仕様が変わってそのプログラムを変更しなくっちゃならない時はどうする？元のコードを書き換えてエラーチェックしてから、またコピペしなくちゃならないピヨ。そうなると、人間の記憶は完璧じゃないから、変更忘れが生じる可能性が高い。そうなったらバグ発生！ってわけピヨ。あー想像するだけでも鳥肌が立つよ。あっボク鳥だった。それはともかく、一箇所変更するだけで深夜まで残業して変更するの誰でも嫌だろ？
ボクは何故かオブジェクト指向を禁止しているブラック企業に働いた事あるけど、そりゃもう地獄だったさ。勿論モジュール化はしてあったんだけど、オブジェクト指向は階層型だから人間が把握しやすいけどモジュールはそんな関係ないから数万行になった時ややこしくって仕方が無い。アーやだやだ。賢明な読者は継承でコードの重複を撲滅しよう！
継承はこれでおしまい。じゃあ次いくピヨッ
いよいよ最後になりました。最後は多態性ピーヨ。これまた難しい名前だね。もっと簡単な名前無かったのかなぁ。なんか箔をつけるために知ってて難しい名前を考えたような気がするピヨ。それはともかく、内容はやっぱり簡単だよ。リラックスしてね。
多態性とは要するに呼ばれたオブジェクトが動作を決めると言う事なんだ。何でそんなことをするかって？それは、呼び出す側がいちいち「あーこれはColorオブジェクト君だからこうやって、ApplicationColor君の場合はえーと・・・」と考えていたらサブルーチン化出来ないからだよ。オブジェクトが増えるたびに呼び出し側が処理を追加していくよりも、呼び出される側が処理を書いた方がコードの重複が無くなるピヨね。呼び出す側が処理を書いていたら呼び出し側の数だけコードが重複するけど、呼び出される側で処理を書いたら1箇所で済むってわけさ。全てはコードの重複が憎いぃと言う事なんだ。コードの重複はそこまで嫌われているんだ。多態性についてはこれでおしまい。纏めに入るぞ。とぉー。
まとめだよ。どう？オブジェクト指向プログラミングって思ったよりも難しくないと感じたと思う。熟練の人は足りない説明が目に付いたと思うけど、始めから全て覚える必要は無いし、僕らはプログラミングする側だから美しい理論よりも役に立つ実践的思考の方が大事なんだよ。この記事の内容を覚えたら後は実践あるのみ！オブジェクト指向プログラミングなんて怖くない。もともと楽をするために作ったものなんだから使って損は無いし、そんなに難しくはないのさ。
ということでお後がよろしいようなので、これにて御終い。一件落着～落着～
ではオブジェクト指向プログラミングの基礎をつつこう。オブジェクト指向には三つの要素があるピヨ。カプセル化、継承、多態性だよ。また三つ？人間って三つの考えが好きだね。何だか難しそうだけど内容はそんなこと無いよ。名前が難しそうだからそう思うだけだよ。だから肩の力を抜いて一緒に羽ばたこう。
じゃあ最初はカプセル化をつつこう。カプセル化って何だろう？初心者の方は連想できないと思う。ウルトラマンのカプセル怪獣？お薬？閉じ込めるの？・・・そんなわけが分からない事しか思い浮かばないよ。だから名前を気にしちゃだめピヨ。構造化プログラミングを思い出そう。もし構造化プログラミングが分からない人は冒頭近くの「前回」のリンク先を読んでから戻ってきてね。そのまま帰っちゃいやよ。
ここを読んでいると言う事は構造化プログラミングはバッチリだよね。構造化プログラミングでサブルーチン化が重要だと言う事は分かってもらえたと思う。その考えをさらに発展し、プログラムが扱うデータも外部から見えなくするのがカプセル化なんだ。初心者の方はここであれ？となると思う。「データって何？データはサブルーチン化していないの？」ってね。データと言うのは変数とかの事で、実のところ当時1960年代はそうだったんだ。変数はどこからでも見えるし、外部から買い変え放題でプログラムがよくバグっていたんだ。だからプログラムが持つデータの「変数」を隠蔽しようというのがカプセル化って言う事なんだ。思ったより簡単でしょう？プログラミングの初心者はぴんと来ないかもしれないから実例を、プログラム言語ごと記事で書いておくピヨ。プログラム言語ごとに少しずつ違うからね。今の所は変数はなるべく隠蔽した方がいいと覚えるだけでいいピヨ。素直さが肝心だよ。
次は継承をつつこう。継承？これまた難しい単語だねぇ。名前だけで嫌になるピヨ。だけどこれも案外簡単だから頭を白紙にして聞いてね。継承とはコードの重複をなるべく無くすためのものなんだ。プログラムは結構似た処理を書くことが多いんだ。じゃあ、どうやってその重複を防ぐのかと、当時の偉い人たちが頭を悩ました結果コードを引き継げばいい事を思いついたんだ。それが継承ピヨ。親から子へ遺伝子を受け継ぐってわけさ。
初心者の方はコードの重複が如何にバグを生むかぴんとこないと思う。だけどコードの重複はバグの元なんだ。何でかって？コードがほとんど同じだったら打つのが面倒だし、開発の効率性を高めようと思えば、オブジェクト指向を知らない大概の人はプログラムをコピぺすると思う。だけど、後でソフトの仕様が変わってそのプログラムを変更しなくっちゃならない時はどうする？元のコードを書き換えてエラーチェックしてから、またコピペしなくちゃならないピヨ。そうなると、人間の記憶は完璧じゃないから、変更忘れが生じる可能性が高い。そうなったらバグ発生！ってわけピヨ。あー想像するだけでも鳥肌が立つよ。あっボク鳥だった。それはともかく、一箇所変更するだけで深夜まで残業して変更するの誰でも嫌だろ？
ボクは何故かオブジェクト指向を禁止しているブラック企業に働いた事あるけど、そりゃもう地獄だったさ。勿論モジュール化はしてあったんだけど、オブジェクト指向は階層型だから人間が把握しやすいけどモジュールはそんな関係ないから数万行になった時ややこしくって仕方が無い。アーやだやだ。賢明な読者は継承でコードの重複を撲滅しよう！
継承はこれでおしまい。じゃあ次いくピヨッ
いよいよ最後になりました。最後は多態性ピーヨ。これまた難しい名前だね。もっと簡単な名前無かったのかなぁ。なんか箔をつけるために知ってて難しい名前を考えたような気がするピヨ。それはともかく、内容はやっぱり簡単だよ。リラックスしてね。
多態性とは要するに呼ばれたオブジェクトが動作を決めると言う事なんだ。何でそんなことをするかって？それは、呼び出す側がいちいち「あーこれはColorオブジェクト君だからこうやって、ApplicationColor君の場合はえーと・・・」と考えていたらサブルーチン化出来ないからだよ。オブジェクトが増えるたびに呼び出し側が処理を追加していくよりも、呼び出される側が処理を書いた方がコードの重複が無くなるピヨね。呼び出す側が処理を書いていたら呼び出し側の数だけコードが重複するけど、呼び出される側で処理を書いたら1箇所で済むってわけさ。全てはコードの重複が憎いぃと言う事なんだ。コードの重複はそこまで嫌われているんだ。多態性についてはこれでおしまい。纏めに入るぞ。とぉー。
まとめだよ。どう？オブジェクト指向プログラミングって思ったよりも難しくないと感じたと思う。熟練の人は足りない説明が目に付いたと思うけど、始めから全て覚える必要は無いし、僕らはプログラミングする側だから美しい理論よりも役に立つ実践的思考の方が大事なんだよ。この記事の内容を覚えたら後は実践あるのみ！オブジェクト指向プログラミングなんて怖くない。もともと楽をするために作ったものなんだから使って損は無いし、そんなに難しくはないのさ。
ということでお後がよろしいようなので、これにて御終い。一件落着～落着～
スポンサーサイト
