私とポリモーフィズムの出会い

http://el.jibun.atmarkit.co.jp/genmaicha/2012/12/2-7b17.html#comments
>みながわけんじ 2012年12月15日 (土) 13:53
>ポリモに出会って価値観がどうか変わったのか具体的に記述してください。
>マジな議論をしているので、へたに雰囲気や印象のみの意見は、これ以上は無視させていただきます。時間の無駄ですので。

ここのからの流れでー
私としては、余談として、自分の例をあげただけなんだけなんだけど・・・
まぁ、構造体に関数つけてなにがおいしいの？って思っていた爺プログラマがクラスの派生というものに衝撃を受けた流れってのは、
同じように考え、今でもそう思っている人に、

「あぁ、そういう考えもあるかもね」

程度に思ってもらえるといいかなーってな希望的観測を含めて、書いておくのもいいかなーと思うので、
こちらに書き出してみます。

DOS時代、C言語で仕事していた私は、C++という言語のclass構文をみてもピンとこなかった。
structに関数が付いただけ？これが最初の感想。
privateなどはどうでもよかった、構造体なんだから、全部publicで使うのが当たり前で、privateなんて、
使い方を制限しているだけじゃね？なんでそんなことするの？と思った。
そんな感じで、C++いらねーCでいいやんと思っていた。
自分にとってメリットが見えないのだから・・・幸い、C++はCとしても使えたわけで、そういう意味でも、
C++固有の機能に関しての興味は相当薄かった。

時代は、Windowsになり、C++を強制された。
MFCを使うのか、Win32APIだけでやるのかという最初の壁は、両方試して、雛形としてMFCを使ったほうが楽だと思ったので、
MFCを選択した。
・・・が、しばらくはWindowsの仕様なのか、MFCの仕様なのか区別がつかずに振り回されたｗ
MFCはWin32APIの拡張または限定仕様と考えるようになって、そこは落ち着いた。

CAD/CAMというアプリケーションを作成していたので、あつかうデータの種類が多彩だったのですよ。
んでもって、操作としては同じようなものが多かったんです。
削除や移動、複写、変形などなど。

DOS時代は、そのデータフォーマットとして、全てのデータをあらわせられるものを用意していたんですねぇ。
具体的には、直線のデータには不要な、円弧の半径データとかをダミーとして用意していたような感じですね。
これは、メモリに確保するサイズを固定サイズにしたほうが楽だったからというのと、関数に渡すときに、
同じものを渡すほうが楽だったからです。

でもって、データ自体に自分はなんのデータなのかを意味するIDを振り分けたと。
操作側、つまり関数側は、IDをみて、処理を分岐させていたのです。
IDが増える、つまりデータ種類が増えるたびに、全ての関数を修正する必要があったんですねぇ。

そこで、ポリモーフィズムのサンプル（まぁ、悪名もありますが、動物の鳴き声のやつです）を見て、衝撃を受けたんですよ。
異なるデータを同じように扱ってる！！ってな感じで。
そこから、データ側に処理を移すことで、データごとに異なる処理を同じような処理として扱えることに気が付いたわけです。

C++で、データの基本クラスを用意し、そこから派生させたクラスとして、直線や円弧を用意するように変えました。
操作側は、基本クラスのメソッドを操作すれば、直線なのか円弧なのかを気にする必要がなくなりました。
表示するメソッドを用意すれば、そのメソッドを呼べば図形が表示されるわけで、直線なのか円弧なのかは、表示を
命じている側には関係なくかけるわけですよ。
従来の方法では、表示関数にデータを渡して、表示関数の中でifやswitchで分岐させていたのを、
直線クラスや円弧クラスというクラスの中で、自分の分だけに集中して書けばよくなった。
従来の方法でも、直線表示関数、円弧表示関数など、分岐先として別関数に分けていたわけですがー
データを作成した時点で、その後のコードに分岐がなくなった点、直線なら直線のことが一箇所（直線クラス）にまとめられる点で、
クラスを使ったほうがスッキリしたのです。
さらに、データ種類が増えても、操作側を変更せず、追加したデータだけを作れば良いというのは、従来のやり方ではできないことでした。

CADというアプリケーションを作る目的は同じで同じものを作ったわけですが、オブジェクト指向っぽい考えを用いることで、
作りやすさや修正しやすさは大きく変わったのですよ。

それまでの価値観は、

「操作する側が主であり、データはデータでしかなく、操作側が全てのデータを管理するのが、当たり前でわかりやすい」

だったのですが、

「データ側に処理を任せるほうが、わかりやすいし、楽」

というように、変化したんですねぇ。

データ側に処理を任せることで、データは抽象化しやすくなり、データを抽象化することで、データを管理する側の処理は、
データ依存しない簡素なものにできる・・・ってわけです。
こーバラバラだったものが１つに繋がっていくような感じですね。
privateなどの意味もここでわかってきました。
最初作ったクラスのメンバは全部publicで、作っていたわけですが、外部から使わないものは、外部に見せないことで、
外部から使われない、つまり、後から変更しても外部に影響がないってところに落ち着いたんですねぇ。

また、データ自体が自分の面倒をみるから、使う側は命令だけすればよいことになるわけですよ。
これは、データだけを切り抜いて使えるってことでもあるわけでー
従来は、関数ライブラリとして、よくある処理や演算をまとめていたわけですがー
それに加えて、よくあるデータという状態でまとめられるようになったわけです。
従来でもよく使うデータの構造体を列記して、そのデータを使う関数をセットにすることはできたわけですが、
クラスを使うことで、１つにまとめ、さらに、派生させることで、上位互換の別物を作ることができるわけです。

私の場合、ポリモーフィズムという概念を見なければ、オブジェクト指向の利点はわからなかったわけでー
さらに、仕事でポリモーフィズムがもっとも効果的に現れるようなことをしていたから、利点だと感じることができただけなんですよねぇ。
今の時代では、最初からオブジェクト指向という概念を学ぶのでしょうし、非オブジェクト指向に触れることのほうが少ないのかな？とも思うわけでー
どちらかといえば、若い人が、この文章をみて、

「爺プログラマは、そんな思考をしていたのかぁ」

と思ってもらい、爺プログラマの生態について、理解を深めてもらえたらなーと思いますｗ