私は現在ゲーム エンジンを構築しています (これは 2D レンダラーに関連しています)。たとえば、画像の URL、幅、高さのみを保持するオブジェクト Image を使用するのが悪い習慣であるかどうかを知りたいです。次に、この Image をレンダリングすると、レンダラーはイメージのロードを要求し、レンダラーはイメージのレンダリング方法も認識します。
なぜ私はそのようなアプローチを選んだのですか？
また、長方形には ax、y、幅、高さがありますが、それ自体を描画する方法がわからないため、レンダラーが長方形を描画します。
このアプローチの何が悪いのでしょうか?
明らかに、それは依存します。
「ノードが自分自身をレンダリングする必要があるか」よりも難しい質問をしています。
「オブジェクト/クラスをどのように設計すればよいですか?」というより一般的な質問に対する実際の OOP の回答が必要な場合は、ボブおじさんの SOLID デザインの原則を確認してください。または、 「SOLID Design」で検索してください。
この特定のシナリオでは、そのデータのみを表すオブジェクトと、それらのオブジェクトを描画できる他のオブジェクトを持つことは、完全に有効なアイデアだと思います。このようにして、現在説明しているような、そのデータの複数の異なるタイプのビューに同じ「データ オブジェクト」を使用します。
あなたのアイデアは境界線の MVC または MVVM (原則として) であるため、メリットがないわけではありません。
たとえば、画像の URL、幅、高さのみを保持するオブジェクト Image を使用するのが悪い習慣であるかどうかを知りたいです。
簡単に言えば、いいえ。これ自体は悪い習慣ではありません。<img>タグを作成するための既存の「クラス」であるため、「イメージ」と呼ばれることは悪いことです。そのために別の名前を選ぶのがおそらく最善でしょう。
次に、この画像をレンダリングすると、レンダラーは画像のロードを要求し、レンダラーは画像のレンダリング方法も認識します。
複雑な匂いがします。このオブジェクトは、画像がロードされたときのコールバックを処理するか、画像を同期的にロードする何らかの方法を見つける必要があります (可能であっても、これは悪いことです)。また、画像の読み込みに失敗した場合の対処法も知っておく必要があります。データ オブジェクトを使用するクラスは画像をロードする必要がある可能性が高いため、この複雑さの一部を助けるために、前述の「データ オブジェクト」でpromiseを使用することを検討するかもしれません。
別の観察：「レンダラー」という用語は、何でもすべてをレンダリングできる包括的なものであるかのように使用します。そんなことを考えていると、長期的にはうまくいきません。特定の方法で他のデータのみのオブジェクトをレンダリングする方法を知っている特定のオブジェクトが必要になります。これらの「ビュー」オブジェクトは、ある種の「レンダリング」API を使用してこれらのデータのみのオブジェクトを描画する方法を知っていますが、描画 API はユーティリティとして、またはプリミティブ オブジェクトの描画の複雑さを隠すものとして考える必要があります。「何でも/すべてを描く」方法を知っている「頼りになる人」とは考えないでください。
また、長方形には ax、y、幅、高さがありますが、それ自体を描画する方法がわからないため、レンダラーが長方形を描画します。
いいですね。これを行うことで、必要な方法で四角形を描画できるようになります。たとえば、赤、青、放射状のグラデーション、マトリックスに従って変換されたものなどです。
このアプローチで何が悪いのでしょうか?
何でも... すべて... 何も... しかし、おそらく不要な複雑さです。複雑さが実際には不要であると仮定します。
調べるために何かをコーディングする必要がある場合もあります。
「将来これを使用するために必要なすべての方法は何ですか」または「これを最も一般的なソリューションにするにはどうすればよいか」について考えるのに時間を無駄にしないでください。多くの時間を費やすことになるからです。何もしない。