オブジェクト指向の理解の変化
黒歴史な気がしてしょうがないが、どう理解したのかを思い返してみる。
ここの人に会って、勉強会で講義を聴くまでは自分はオレオレオブジェクト指向に確かにハマってたかも知れない。*1だが、勉強会(しかも終わった後の飲み会)でオブジェクト指向の源流、その背景、それぞれのキーワードの出展、オブジェクト指向と呼ばれる多種の種類の存在を聞いたとききちんと理解できたと思う。
だが、それをすんなり受け入れられたのは、きちんと下地の勉強をしていたからだと思う。*2
とりあえず「操作の塊」を定義するんだと理解した1年目
大学1年、初めてJavaでクラスの話を聞いたときはちんぷんかんぷんだった。そりゃまぁ大学の講義やテキストで読んだってわかるはずが無い。犬？猫？動物？なんだそりゃ？今言わせれば例えが悪い。今でこそ思うが、そんなもので抽象化の概念が考えられるのはプログラムを習う前だ。手続き型の構造化プログラムまで知っていると、抽象化は逆にとっつきにくいのかもしれない。だって具象的に考えてコード各人たちだもん。
とりあえず、同類なメソッドのホルダーなんだなと、勝手に名前空間と混同していたワケだ。
そこから成長したのは半年後位だったか整数型の変数に、「.toString()」かけたときだ。
int, double, float 等の基本型、String を除いて、使用宣言に new をしているのを除けば、「toString」が型ごとに用意されて、結果は違うが呼べることに気がついた。
つまり、整数型も、僕らがクラス宣言して使っているものも、本質的に同じ、「変数を持つ操作の塊」なんだってのに気がついた。
そこからの理解は早かった。メソッドを定義すれば、そのメソッドをインスタンスから呼び出せること、オーバーライドすることで、各々の動作が変わること。
static というキーワードが出てきたときも、使ってみて、「インスタンスに関係なく、メモリ上で1個だけ存在するメソッド、変数の宣言なんだ」と理解した。
だがまだ少し、もう少し理解するには足りなかった。まだ「変数を持つ操作の塊」という理解しかなかったのだ。
多分下地のできた大学2年
理解を早めたのは個人で勝手に勉強していた C++ だった。ここで struct と各種変数を理解したときだ。関数に対し、突っ込む構造体の中によって、さまざまな動作を作ることになった。
構造体は寿命がある。システム開始時から終了まで居るものもあれば、途中で引数に使われて消えるもの、複数のメソッド間でたらいまわしに使われるもの。
そして、それに密着して動く処理、ひとつにまとまらんかな？って、それクラスでできるじゃん。
このとき「寿命を持った一まとめの変数と、それにかかわる処理のセット」だという理解になった。確か大学2年の頭の頃だ。
大学2年の9月、理解は加速した。大学祭でシューティングゲームを作ろうとしたときだ。*3
画像の背景抜き、ウィンドウの出し方、作画方法、ゲームループの作り方。覚えることは沢山あったが、Google先生経由で調べて、理解し、組み合わせるだけだ。
だが、肝心のゲーム進行部分のロジックが思いつかない。
シューティングゲームアルゴリズムマニアックスを購入したが、個々のTipはあるものの、ゲームループに絡めた実装は乗ってるわけではなかった。
もう既に何処のサイトだったか出展を忘れてしまったのだが、画面上の敵、弾、自機は、すべて座標と画像番号、当たり判定を持ってるんだから、同じ変数が少なくともある。なら、それを事前に定義して、継承すりゃええやん。1フレームごとに座標移動と、当たり判定のヒット計算するんだから、それも親に持たせりゃええやん。と書いてあった。
画面上のものをオブジェクトとみなし、オブジェクトの操作をインターフェースに操作を抽象化、仮想クラスで共通する変数を定義し、、、、、といった考え方も新鮮だったが、何よりも。
個々の機能→組み合わせ→設計、ではなく、画面→分解分析→設計というまったく逆の方向での思考があるのかと軽く文化の違いを見せ付けられた。
MVC の基礎を学んだ大学3年
フレームワークなんて大層なものは使っていない。確かPHP5＋Smartyだったと思う。
画面とロジックを分離するという話だ。
知らない頃だったから、Cにあたる箇所に大量のロジックを書いていたが、まぁご愛嬌だろう。*4
それを元にC++の弾幕STGだか作ったのが今でも Vector 辺りに落ちてる。
オブジェクト指向の設計にハマった大学4年
バイトだかで、OpenPNEの画面追加とか、改造をしてた頃だ。画面追加どうしたらええねん？とか思って調べても、大抵のPHPソフトはそうなんだが、「使う」ドキュメントは山のようにあるんだが「改造」「設計」に関するドキュメントはない。
プラグインならまだしも、それもなかったので、あきらめて処理の流れを解析した。*5
Mojavi フレームワークを採用していた、、、、のは後で知ったのだが、MVCがキッチリ分離されていること、機能や画面の追加が、ほかの画面に手を入れずに設定出来ることなど、非常に驚いた。
継承関係をうまく使うことで、このようなコトが実現できるのかと感動した自分は、卒業研究でも似たようなコトを始めた気がする。*6
結局卒論に費やした院2年
ここの人から、「こんなフレームワークあるお」とか「こんな開発手法あんぜ」とか教えてもらっておもしれえ！とか思いつつ、、、、。
大学の研究は仕事に近い手法が中々適用できなくて悩んだ。
*1:きっと今でもオレオレオブジェクト指向を信じていた筈だ。
*2:そう思ってるだけかも知れない。理解に対して見解が変わるのはよくあること
*3:学校の課題と、簡単なアルゴリズム(しかもC向け)やってた程度の学生にしては、相当無茶なことをしようとしてたと思う。
*4:コントローラが頑張るMVCに相当。http://www.jac-net.com/~tarzan/smalltalkers/mvc/mvc.html
*5:これまた無茶したと思う。フレームワークが小さくてよかった。昨今なら、数十Mとか当たり前で、それを追っかけるのは悲惨な状況だからね。
*6:ちょうどこの頃、こういう設計部分の思想で教授と超やりあったなぁ
