なぜオブジェクト指向ではなかったか
プログラミングの歴史が始まった時、ＣＰＵやメモリやディスク(じつはディスクが発明されるより、プログラミングの歴史のほうが古いのですが)といったものは非常に高価でした。そこで、プログラマやシステム設計者は、プログラムを、速く動作するように、メモリをあまり消費しないように、ディスクをあまり消費しないようにと、血を吐くような工夫をしながら作ってきました(吐いた覚えもあります(笑))。
こういったテクニックの工夫はプログラミングの歴史が始まった時点から現在まで続けられていて、ある程度の手法的な完成を見ています。
これらのテクニックは、実社会のしくみコンピュータ内に置換える(モデル化といいます)時に、制限を加えたり構造を変えたりして、よりコンピュータ的な表現に適した形にして、高速化や軽量化(メモリを消費しないこと)を追求するものです。
これらは、高速な動作速度、軽量なサイズと引き換えに、プログラムの拡張性や読みやすさを損なう諸刃の剣です。しかし、それでもそうしないと、実用に耐える性能(速度、メモリ消費とも)が達成できなかったのです。
そして、それができる事にプログラマとしての誇りがあったりもします。
今ではオブジェクト指向が当たり前
しかしハードウェアリソース(ＣＰＵやメモリやディスクなどのこと)のコストパフォーマンスの向上はめざましいものがあります。そうなると、一部の速度的に大変シビアな分野(ゲームや機器制御など)を除き、高速化や軽量化よりも、いかに拡張性を確保するか、いかに自然なプログラムにするかということが重要視されてきます。
そこで注目されてきたのがオブジェクト指向という手法です。
つまり、この手法の方が、実社会に忠実であり、拡張性が高いということです。
そして、メモリ消費や速度的には不利ということでもあります。
1990年代初頭にはまだ珍しかったオブジェクト指向ですが、2000年を迎えた現在では、むしろ開発手法の事実上の標準の地位を確立しつつあります。
おそらく、この時期新たに職業プログラマになろうという方は、最初に触れる開発手法がオブジェクト指向であるという方が数多くいらっしゃるでしょう。
また、自分がオブジェクト指向を活用していることを意識せずに開発されているプログラマもいらっしゃると思います。
ここでは、オブジェクト指向について再考し、その概念が何ら特別なものではなく、ごくあたりまえのモデル化手段であることを確認していきましょう。
用語はとりあえず触れないでおこう
ということで、「継承」とか「包含」とか「集約」とか「ポリモーフィズム」とか「インスタンス」とか「抽象化」とか「カプセル化」とか…ああ引かないで下さい(^^;とりあえずそういう用語は後回しにしましょう。大事なのは用語の知識よりも、まずは雰囲気の把握です(と、言い切ってしまえ！)。
いえ、いきなり用語から入ってもいいんですが…そういう用語も、ごくあたりまえの概念に名前を付けたにすぎないわけでして、そういうのは後回しにしましょう…
…け、決して、説明するのが面倒だとか、そ、そういうことじゃないですよ(^^;
いきなり例題
用語説明とリクツを後回しにするなら実際にやってみるしかないわけです。いくつか例題の候補をいただいたのですが…ええと、主に(私の勤務先の)会社の人間からの要望があって(^^;、やはりＰＯＳレジのシステムにすることにしました。
…マニアックすぎますかねぇ(^^;
いやいや、いやいや、誰だってレジみたことくらいあるはず。
商品を持っていくとピッピッピッとスキャンして値段を表示してレシートを出すあれです。
取りあえず、超簡単なレジのシステムを考えましょう。
実際には現在のＰＯＳレジシステムというのは非常に高度なものとなっていまして、経営に必要な情報を少しでもくわしく入手しようといろいろな工夫を凝らされているんです。
が、ここではそんなことは考えません。経営者の視点とかもナシ。クレジット支払いもしなければ値引きもしない、実にキモチいいプリミティブなレジとします。
さてそれではこの中の処理を考えてみましょう。
えいやっとシステムを図に
…してみましょう。とう！
図の解像度は大きいのですが、モノクロのGIFですのでサイズは７Ｋです。表示をお待ちください。
ってカンジでプログラムの流れを図にしてみました。これはプログラミングの世界では流れ図とかフローチャートとか呼ばれるものを、私の都合で簡略化したりあるいは補足したりして書いたものです。
ソフトウェア業界のプロフェッショナルから見るといろいろといいたいこともあるとは思いますが(^^;、まあ大目に見てください。(笑)
ここで、
っていうのは、いわゆるグローバル変数だと思ってください。プログラム全体のどこからでも見たり設定したりできるデータです。さて、この図をみるとなんとなく雰囲気がつかめると思います。商品をスキャンして、スキャンして…全部スキャンしたらキーボードから金額をいれておつりが出てきます。
もちろん本当のレジはこれにレシートの印字もあるんですが、今回は話を簡単にするために取っ払ってあります。
この図では、まったくオブジェクト指向なんて考えていません。
（実は私は頭の中が自然にオブジェクト指向な考え方をするようになってしまっていて、この図はずいぶん意識して苦労しつつ従来形式を踏襲しています。このため、この図は非常にわざとらしいカンジがするかもしれません(^^;)
図をいじってみる - 布石
さて、上の図はずいぶん長いですね。なんとかならないもんでしょうか。なんとかしてみましょう。たとえば、画面に関係するところを別でまとめてみましょうか。
それ！
これも解像度は大きいのですがモノクロGIFですのでサイズはやっぱり７Kです。表示をお待ちください。
…おいおい、複雑にしてどうするんだ(^^;こんなもん見せるんじゃない。
と思われた方、でもちょっと待ってください。たしかに全体的にはちょっと複雑になっちゃってるかもしれません。
でも、よく見てください。メイン系だけを見れば、以前よりやってることはシンプルだと思いませんか？
メイン系でやっていることは、入力の制御(スキャナとかキーボードとか)と、データの管理だけですよね。
画面のことを考えなくした分、メイン系はシンプルになっているんです。
そして、表示系も、一つ一つの処理はとてもシンプルではないでしょうか。
さらに大きな違いがあります。よく見てください。
がミソです。これを見てるのは画面系だけ、そしてクリアしたり加算したりするのも画面系だけですよね。こういう風に考えたとき、たとえば画面系を「画面オブジェクト」っていう風に考えてみるんです。
そうすると…
なんとなくそれっぽく
…なるといいんですが。そーれー！(モノクロGIF 8Kです)
おお。ほら。なんとなくオブジェクト指向っぽくなってるじゃありませんか。
え。誤魔化されてるような気がします？簡単すぎる？
気のせいです気のせい。もともとオブジェクト指向ってのは大層な名前の割に難しいもんじゃないんです。冒頭でも書きましたが、あたりまえの方法なんです。
メインから、画面オブジェクトに対して、指示をあたえます。
この図でいうと
の部分です。
画面オブジェクトは、それに答えて画面表示に関する処理を行います。
こういうふうに、処理をオブジェクトの中に閉じ込めて、外部(この例ではメインですね)からは、ただ呼び出すだけにするという手法を、オブジェクト指向では「カプセル化」というふうに言っています。
呼び出されるところ(上の図では、オブジェクトからちょこっと頭を除かせている部分)のことをオブジェクト指向では「メソッド」と言うことが多いようです。
別にオブジェクト指向でない考えと比べても、やってることはそんなに変わらないでしょう？
まとめ方がちょっと違うだけです。
一般的にオブジェクト指向では、「ある名詞に関する処理」をまとめると、上手くいくことが多いようです。
語弊はあるのですが、それをまとめて、メソッドを作ることをオブジェクト化という、といってしまってもいいくらいです。
＃この例では「画面に関する処理」をまとめています。
このほかにもいろんなオブジェクト指向の手法があるのですが、この時点では触れないでおきましょう。…あとで触れますね。
も、メイン系からなくなり、事実上「グローバルデータ」が消えました。