厳密な光線追跡 - その15

前回、光線追跡エンジンの大まかなオブジェクト設計をした。比較的簡単で素直にできた。その中で、中間的なオブジェクトやお互い保持し合うオブジェクトがある。もう一度整理をかねてまとめておく。最近この程度でもすぐわからなくなってしまう。思考力の老化はひたひたと。おおぉ、自分で書いときながらむちゃ、怖いわ。

4.3  オブジェクトの整理

• 光学系オブジェクト
  • 媒質オブジェクトとバウンダリオブジェクトを保持する
  • それぞれの順番を保持する
  • 追跡計算のための関数をキャッシュする
  • 近軸マトリクスを計算し、保持する
• 媒質オブジェクト
  • 媒質一種類につきオブジェクト一つ
  • 屈折率を計算し、値をキャッシュする
• バウンダリオブジェクト
  • 面形状オブジェクトを保持する
  • グローバル座標と面座標の変換を行う
  • 変換行列をキャッシュする
• 面形状オブジェクト
  • 面の式を保持する
  • 式の関数形をキャッシュする
  • 光線との交点と屈折光線の方向ベクトルを計算する
• 光線オブジェクト
  • 光線素（一つの媒質に含まれる光線）を表す
  • 光線の属性を保持する
  • 追跡停止条件を保持する

といった感じ。普通のプログラミングとしてはそれほど複雑ではない。でもMathematicaパッケージとしてはごちゃごちゃした感じになる。こういうごちゃごちゃをMathematicaでどうすっきりと記述するか、がポイントになる。

こういう設計はMathematicaで書くためだけでなく、例えばObjective-Cに落として高速化するときにも使える。というか、Objective-Cで書くときの方が素直な表現がやりやすい。

4.4  オブジェクト指向なMathematicaパッケージ

僕にとってオブジェクト指向設計というのは重要で、コーディングするときはどんな言語を使うにしてもいつも意識している。僕にとってはオブジェクト指向設計はスパゲティコードを避けるための手段である。

Mathematicaはもともと数式処理システムで、他の数式処理システムと似たようにLISPのリスト処理を基本としているので、オブジェクト指向的なプログラミングは考えられていない。しかしLISPにもオブジェクト指向の考え方を取り入れた方言があるように、Mathematicaにも同じようなやり方でそのスタイルを取り入れることができる。

そもそもオブジェクト指向とはどういう設計方針かというとWikipediaには

• カプセル化
• インヘリタンス（継承）
• ポリモーフィズム
• ダイナミックバインディング

を文法的にサポートする言語をオブジェクト指向プログラミング言語と呼ぶらしい。

しかし僕のイメージではオブジェクト指向プログラミングは

1. 独立した内部状態を持つ部品（オブジェクト）の集合として全体を設計する
2. オブジェクト間でメッセージをやりとりすることだけで動作する
3. 同じ構造を持つ部品を独立に複数個、生成したり破棄したりできるようにする

が最低要件というつもりでいつもコードを書いている。ダイナミックバインディングは確かに役に立つけど絶対要るかというとそうでもないし、ポリモーフィズムはもちろんあったほうがいいけどなきゃ困るというものではないし、インヘリタンスもそりゃできたほうがいいね、という感じだけどどれもなくてもオブジェクト指向な設計は可能だと思っている。

絶対やらなきゃいけないのがカプセル化で、これができていないとオブジェクト指向言語を使ったとしてもオブジェクト指向設計にはならない。僕のイメージの3つの要件の最初のふたつはカプセル化をどうやってやるかと言っているに過ぎない。

例えばMac OS XのCore FoundationフレームワークはCでオブジェクト指向の考え方を取り入れたフレームワークで、フレームワークを使うプログラマから見たときにはWikipediaにある４つの要件を全て満たしていて、さらに僕のイメージを３つとも満足している。もちろんCベースなのでインヘリタンスやポリモーフィズムはAPIの見た目がそうなっている、ということでしかない。