Solitaire

ゲームエンジンを組んでいて、デバイスへの依存度が高いと、キャストや抽象化の数が減るから
パフォーマンスは上がるかもしれないけれど、後で違うデバイスへ同じロジックで乗せ替えをしたい時に難しくなる。

デバイスではなくて、ドライバ（API) だけれど、DirectX と openGL のそれぞれに依存している部分を
どの程度依存を強くするか。というのが、両方に対応させるポイントかなと。

たとえば、C++ で InterfaceClass を定義して、それを継承したクラスが
DirectX用の Vector, openGL用の Vector クラスを内包していて
Interfaceは統一されている状態であっても、そのポインタを更に DirectX 用の API に渡すには更にキャストが必要。
しかも、そこに必ず DirectX 用の Vector オブジェクトがこないといけない。
ポインタとしては、抽象クラスに一度キャストされているし、受け口もそうすれば受け取れるけれど
中身が違ったら結局実行時エラーが出る。
それじゃ、抽象化に成功しているとはいえない。
組む時の苦労は何も減らない。むしろ、キャストしてただ単にパフォーマンスが落ちるだけじゃないのか？

どんなに Vector や Matrix, Light を抽象化しようが、最終的にはそれぞれの API が指定しているオブジェクトを渡さないといけないんだもん。

って言うことで、余り依存関係を弱くしても、それがシステム的にいい設計とは限らないと思うわけです。
じゃあ、どこまでを依存にして、どこからを非依存にすれば
ゲームエンジンとして、性能がいいのだろうか？

おそらく、デバイス依存する部分はがっつり依存する。つまり描画周り。
そこを、きちんと切り出しておいて、DIコンテナみたいに、動的に入れ替えが出来れば問題がないはず。
アスペクト指向ってやつかな。

で、ゲーム側ロジック側では抽象クラスとしてしか扱わない。
つまり、InterfaceClass のポインタを受け取って、その関数を扱うけれど、オブジェクトには直にアクセスしない。
描画部分だけは、InterfaceClassのポインタではなく、完全にデバイス依存のオブジェクトポインタを受け取る。
これで、ある程度は分離できるはず。

Javaのフレームワークで、散々アスペクト指向というものに触れてきたけれど
それが役に立っている感じ？

まあ、オブジェクト指向、アスペクト指向、エージェント指向って色々あるけれど
プログラムを本格的に組んでいると必ずぶち当たる壁に対する、解決手段思想だよね。

たまに、そういう思想を一切勉強しないでプログラムを組んでいる人を見かけるけれど
そういう人って、性格にもよるけれど、ちょっと困る場合が多い。

大抵の場合そういう人のプログラムは読めないし、後から変更が出来ない、どこかをいじると次々と動かなくなる。
という場合が多いからだ。

個人差はあるけれど、自分が見かけた人たちは、得てして頑固な性格をしていて
根拠がない理由で頑固なんだよね。

これはどうしてこういう方法を使っているの？
このカラムは何でこのテーブルにあるの？
って聞いても、なんとなく。って答えるんだよね。

まあ、話はそれたけれど、その思想への好き嫌いはそれぞれあるだろうし
勉強しなくても、別にいいんだけれど

他人が読めるプログラムを組んで欲しい。
それに付きます。
動けばいい。っていうプログラムの組み方する人のプログラムはもう二度と見たくないなぁ・・・