世界を動かす技術を、日本語で。
ご不明点があれば 具体的なご要望 をお知らせください。
真面目な質問なんだけど、DODって実際には配列プログラミング以上の意味があるの？
うん。
アンドリュー・ケリーの「実践的データ指向設計」ってトークを見てみて。彼が以下のテクニックを紹介してるよ：
結局のところ、KISS（シンプルに保つ）と不要なオーバーヘッドや間接参照（例えば、仮想テーブルやC++ STLコンテナなど）を避けることが大事なんだよ。そうすることでハードウェアを最大限に活用できる。
そうだね。配列プログラミングは、現代のハードウェアではDODと重なる部分が多いけど、アタリSTでプログラミングしてたらそうはならない。最適なデータフォーマットが配列指向でない場合もあるし、その問題に対するメモリアクセスパターンが別のものを必要とすることもある。ホットデータとコールドデータについても考えないといけないけど、これは配列とは関係ない。
つまり、車のオブジェクトがタイヤのオブジェクトを子供として持つストリートオブジェクトを作る代わりに、必要なホイール回転のタイプに合わせたデータ型を指す配列を持つってこと。答えが配列であることが多いけど、問題によっては他のものになることもある。データ駆動設計はそんなに複雑じゃなくて、抽象を考える代わりに、データが最も一般的な変換に対応できる形を考えるってことだよ。
この考え方の本質は、アルゴリズムの設計においてデータを最優先にすることだよ。例えば、物理エンジンで衝突検出を最適化しているとき、解決すべき問題のデータの流れを考えることがコードを書く上での主要なドライバーになる。まずデータを定義して、そこから構築していくんだ。アプリケーションの種類によってデータの形は異なるから、最適なコードの形も変わる。例えば、物理エンジンは空間ハッシュのようなものを使うけど、実行中に追加や削除ができるかどうかで最適化が変わる。3Dレンダラーは大きなマトリックスや頂点データのバッファを扱うし、ゲームは通常、長生きするものと短命のものがたくさんある。マイク・アクトンのトークの重要なメッセージは、「異なるデータがあれば、異なる問題がある」ってこと。ECSシステムはすべての問題を完璧にデータ指向で解決する万能薬ではないけど、一般的にはオブジェクト指向の階層よりも柔軟性がある。だから、成熟したオブジェクト指向のコードベースよりもECSフレームワークで「ほぼ最適な」コードを書く方が実現可能なんだ。でも、重要なメッセージは「Xフレームワークを使え」じゃなくて、「まずデータを定義しよう」ってこと。
ECSに関する私の経験は、「ECSシステム」を使うべきじゃないってこと。ECSをそのままやればいいんだ。すべてのパーティクルの配列を持って、速度に応じてすべての位置を更新するだけ。get_all_entities_with()みたいなフレームワークは使わない方がいいよ。構造体でパーティクルを定義して、{vector positions, velocities;}って感じで。まあ、並列配列を管理するのは結構面倒だけど、全てをやるフレームワークを使うよりは、並列配列のクラステンプレートで解決した方がいいよ。とはいえ、並列配列が本当に必要かは微妙で、AoSでも大丈夫かも。だって、通常は各フレームで各パーティクルの各フィールドに一度触れるだけだし、順番通りにやるからね。
DoDって、信じてからじゃないと意味が分からないことの一つだと思う。KISSの啓示みたいなものを経験しなきゃいけなくて、一般に入手できるDoDに関する情報はそれを助けてくれない気がする。さらに、DoDに関するすべてが過度に具体的なC++の最適化アドバイスに引っかかるのも良くないよね。
これは基本的に私がいつも物を設計してきたやり方で、これがベストなアプローチだと思ってる。データをモデル化する正しい方法を選べば、アルゴリズムは自然に流れ出てくる。私の意見では、「データ」コードを読むのは「アルゴリズム」コードを読むよりも認知負荷がずっと低い。構造体の定義みたいな宣言型の型をたくさん読むのは、それに対して動作する関数を読むよりもずっと楽だし、理解するためにあまり「状態」を維持する必要がないから、潜在的なバグを見つけるのもずっと簡単なんだ。だから、ECSの概念は一般的に理解しやすいと感じているのかもしれない（もちろん、使いやすいかどうかはフレームワークが何を公開しているかや、チームがどう使うかに大きく依存するけど）。
アイデア自体には価値があるけど、問題は人々が抽象なしでデータ指向システムを設計する時だね。実際、データの周りに良い抽象を見つけるのは難しいことが多い。システム、データ、機能が変わる必要がある時に問題が出てくる。だから、データフローについて考えるのは素晴らしいけど、それに関連する抽象、つまりシステムがどこでも変更を伝播させずに進化できるインターフェースについて考えることも重要なんだ。