Class

その頃僕は、プログラミングの真似事として、REALbasic でちょっとしたシェアウェアを作ったりしていました。

GUI アプリケーションの基本的な実装方法をそこで（感覚として）把握できたのは、後々役に立ちました。例えば、ウィンドウやコントロールの生成と管理の方法や、イベントの扱い方、ファイルの読み書きとそのタイミング、状態の持ち方とその表現、等々。

全てのコントロールが、要はグラフィックを描画する汎用オブジェクトのサブクラスであることを改めて意識できたのも良かったと思います。完成されたアプリケーションを使っているだけだと、各コントロールがまるで生きた個体として独自に発生したかの見えますが、中を覗けば、全て同じ分子構造を持った「絵」なのでした。

OSが様々なクラスを用意していて、基本的にはそれらのインスタンスを組み合わせればよいということ。もし機能を拡張したければ独自のサブクラスを作ればよいということ。そういった基礎的な方法論も分かってきました。

オブジェクト指向の環境において分かりにくかったのは、概念的なクラスについてでした。コントロールやコンテナーといった目に見える部品のクラスはなんとなく分かるのですが、例えば日時とかデータストリームなどの目に見えない概念上の要素までもオブジェクトとして部品化するというのは、なかなか馴染めませんでした。それらは非常に文脈的であり、サブジェクトに近いと感じたからです。ただしそれらにも共通の型としていくつかのプロパティがあり、自分自身の性質を表現／変更するためのメソッドを持たせることで、オブジェクトとして便利に利用できるということが分かると、なるほどという感じでした。

それから、これも基本的なこととして、メモリの消費量とパフォーマンスが比例関係にあることも実感できました。単純に、多くの情報を変数にして使い回せば処理は速くなりますが、メモリの消費が増えると同時に、バグも発生しやすくなります。そこはバランスの問題です。サブルーチンをどれぐらい細かく構造化するのかというのも、同様に経験的なバランス感覚が必要だと思いました。

いずれにしても、if 文を重ねた条件分岐で処理を変更するような書き方をしていると、簡単にプログラムがぐちゃぐちゃになることが分かりました。そういう作りだと、あらゆる状況を想定して各オブジェクトの動きをテストしないといけなくなります。そうではなく、オブジェクト同士がお互いの（あるいはユーザーの）文脈にできるだけ無関心でいられるようにするのがコツだと思いました。GUI においては、状況は無限にあるからです。