バカになるオブジェクト指向プログラミング講座(ドラフト版)

※この記事を読んでも、OOPについて理解は深まりません。嘘だらけでバカになります。



序章　混沌の時代

その昔、
ソースコードに秩序は無く、
そこにあるのは混沌でした。

少しでも速く、
少しでも小さく、
そのために無数の“goto文”と“グローバル変数”が偏在していました。

このようなソースがそれこそ無数に…
【N88日本語BASIC (無茶苦茶な行数に飛ぶIF命令)】

【N88日本語BASIC (グローバル変数がいっぱい！)】


ああ今の時代、
“Hello, world!”をコンパイルしただけでも何KBになることか…！

“goto文”と“グローバル変数”はプログラマーの理解を阻害し、
ソースコードは誰にも触れないものと化していく…

そんな時代でした。



2章　“構造化プログラミング”の時代

混沌に一筋の秩序をもたらす者が現れました。
その名も、勇者“エドガー・ダイクストラ”。

彼はソースコードの中を、3種類の論理構造に分けました。
そしてその論理構造を意識してサブルーチン化すれば、
ソースコードは理解しやすいものになると発表したのです。

• 順次
  【C言語　(順次改善前)】
  【C言語　(順次改善後)】
  
  
• 反復
  【C言語　(反復改善前)】
  【C言語　(反復改善後)】
  
  
• 分岐
  【C言語　(分岐改善前)】
  【C言語　(分岐改善後)】

“goto文” と“グローバル変数”はサブルーチンという壁に阻まれ、

限られた場合でのみ使われるようになりました。

(後にこの一部は、“例外”とか“静的メンバ変数”とかに名前を変えて姿を現します。
まあ、それはまた別の話です。)

この働きにより、

ソースコードに構造化プログラミングという秩序が生まれたのです。

3章　状態と動作

構造化プログラミングが普及するにつれ、
小さな混沌が芽生えることになりました。

それは引数の数です。

何も考えずにサブルーチン(以降は関数を記載)化すると、

自然と引数の数が増えていくのです。

しかしそれは、大きな問題にはなりませんでした。

引数を構造体にまとめておけば、
簡単に引数の数を減らすことができたからです。

【C言語 (引数を減らすサンプル)】

そしてこの構造体が、
ある種の状態を指していることに気がつく人がいました。

【C言語 (犬サンプル)】

これにより構造体の意味がハッキリしました。

状態(構造体)と動作(関数)が手を取り合った瞬間です。

4章　“関数ポインタ”

状態と動作は、
関数の引数型によって結びついていました。

しかしこのままでは、
状態からどのような動作があるのかまではわかりませんでした。

出力できるのか、
入力できるのか、
はたまたどこかと通信するのか、
それは関数の引数をチェックしていく必要があります。

また動作から同じ状態を使う動作がどれだけあるかもわかりません。

せっかく同じ状態を使うにも関わらず、
動作と動作を組み合わせるにはその動作の存在を*知っている*必要があったのです。

【C言語 (犬サンプル改善前)】

しかしある人は気が付きました。

ある動作を行えることそのものが状態なのではないかと。

つまり動作も状態の延長線上として捉えることができると考えたのです。

関数ポインタを使えば、
状態の中に関数ポインタを入れて動作と一体化させることができます。

【C言語 (犬サンプル改善後)】

今度は、状態と動作が一心同体となったのです。

5章　“オブジェクト指向プログラミング”の時代

※ここからJavaで書く予定。

状態と動作はひとつとなり、
プログラミングに秩序の光が差し込みました。

でもこれはきっかけにすぎません。

これをさらに応用・発展していくことで、

新たな可能性が生まれました。

• オーバーロード
• オーバーライド
• 継承
• ポリモーフィズム
• デザインパターン
• 【とにかくいっぱいサンプルDA！】※優先度を決めてTOP5くらい出せばいいかな。

ここにオブジェクト指向プログラミングという抽象化は、
ひとまずの完成を見せたのです。

終章　そして“関数型言語”の時代へ…

オブジェクト指向プログラミングの抽象化は見事なものでしたが、
それだけでは上手く抽象化できない問題もまだ残っていました。

関数を呼ぶ順序がある程度決まっているものや、
ループ処理の中身だけ後から変更したい場合です。

データベースのオープン・クローズはほとんどセットと言ってもいいですが、
その途中の処理は多岐に渡ります。

オープン～クローズまでの流れを関数化するのは難しかったのですが、
仮にオープンとクローズの間の動作を関数の引数で渡したをしたらどうでしょうか。

今まで複数箇所にあったオープンとクローズが１箇所にまとまります。

オープンやクローズの問題に直面したら、
そこだけに注力すれば修正することができるようになるのです。

ループの場合も、
ループの中身を関数の引数で渡せたら…

仮に超高速ループを誰かが開発し、
中身を引数で渡すだけでその恩恵を受けられるとしたら…

何が言いたいか？

関数に関数を渡せるべきであり、
関数は関数を返せるべきだということです。

これを簡潔に記述できるならば…それが関数型言語の入り口です。

新しい秩序の光が、
あなたにも見えてきませんか？

終わり



※要望があればちゃんと書くかも。…誰もいないよね？