現在、いくつかのクラス (Application、Graphics、Sound) を持つ DirectX エンジンがあり、それぞれが約 1,000 行で、それぞれが相互に参照しています。最初は、D3D デバイスを渡すようなクラスやものの使用を制限しようとしましたが、代わりに作成しましたすべてのクラスが使用するのはグローバルですが、他のすべてのエンジンでは、すべてが多くのクラスに分割されており、 Engine->GetRenderer->Render(MyD3DContext); のようなものがあることがわかります。MyD3DContext をグローバルにして、それを Render 関数で直接使用しないのはなぜですか?そして、私が理解できない最後の 1 つのことは、互いに独立して動作するクラスをどのように作成することになっているのでしょうか?奇妙に聞こえます。
4 に答える
まず、なぜそれが非常に非効率的だと思いますか? コーディングと保守がはるかに簡単であるだけでなく、非常に高速です。OOP はボトルネックではなく、複数の開発者と複数の関心事 (実世界のゲームなど) を持つ大規模なプロジェクトにとってはメリットです。
「ゲーム」について言及したので、例を挙げましょう。
ゲームはシミュレーションです シミュレーションにはエンティティ (オブジェクト) が含まれます。オブジェクトは何かを行うことができ、属性を持ちます。したがって、オブジェクトは属性とアクションのカプセル化のようなものです。これが「オブジェクト指向プログラミング」における「オブジェクト」を作るものです。シミュレーターの架空の工場で作成されていると考えることができます。オブジェクトの設計図は「クラス」であり、 と呼ばれencapsulation
ます。
これらのオブジェクトのそれぞれは、おそらく何らかの高度に数学的な Half-Life-2 (ソース) レベルの物理エンジンを介して、あなたの世界にバインドされています。各クラスの「物理」をコーディングしたくないでしょう。代わりに、クラス (またはインターフェイス) "IPhysics" から継承します。そして、重力を 10.0 から 15.0 に変更するたびに、この値が「世界」シナリオ全体に伝播されます。これはinheritance
。
ゲーム内の各オブジェクト、たとえば、Half-Life-2、Gordon Freeman は同時に「プレーヤー」として機能し、「スクリプト化可能」として機能できます。これがポリモーフィズムです。異なるタイプで動作する 1 つのオブジェクト。
ご覧のとおり、OOP で架空のゲームをモデル化して提示するのは非常に簡単です (そして非常に効率的です)。
それはひどく非効率的ではありません。そして、なんらかの OOP の紹介が必ず必要です。多分オンラインでも何か
オブジェクト指向デザインにはいくつかの大きなテナントがあります。特に、コードの再利用/モジュール性とスコープ/分離です。グローバルは、大規模な開発作業にうまく対応できず、常に問題を引き起こすため、最近は一般的に眉をひそめています。そのため、OOは、特定の呼び出しの範囲を、機能を実行するために必要な最小限に制限しようとします。
モジュール性/再利用に関しては、サブモジュールが大きくなるほど、一般的にはより具体的になり、よりモジュール化されたチャンクに分割された場合に可能なすべての目的に適合する可能性が低くなります。その結果、わずかに調整された目的で同じコードを書き直す時間が短縮されます。これにより、新しいコードの実装中に中断する可能性のある隣接する目的も削減されます。これにより、実装がより効率的になりますが、実行時にわずかなコストがかかる場合とない場合があります。おそらくそうではありません。Render()を実行するのに、ルートモジュールで定義されているか、構成されたオブジェクトの深部にある複数のレイヤーで構成されているかに関係なく、バイナリを少し増やす必要はありません。それはまだ単なる関数ポインタです。
これらは単なる一般的な概念なので、好きなものを選んでください。
それがお役に立てば幸いです。
はい。
プロジェクトが大きくなるにつれ、1 つのグローバルな何かを持つと膨大な数の問題が発生します。また、いくつかのポインターをトラバースすることも特に非効率的ではありません。テストを実行して非効率的であることが証明された適切な領域の効率を心配し、常にコードの明確さと分離を維持するように努めてください。
非効率性が心配な場合は、まさにそのような構造を備えたテスト アプリをまとめてみてください。また、すべての逆参照を行うのにどれくらいの時間がかかりますか。たとえば、目に見えるポリゴンのリストを作成することは重要ではないことがわかります。
適切にカプセル化された非グローバル オブジェクトを持つことの利点を理解する唯一の方法は、プロジェクトが成長し、物事を変更するときです。