ゲーム開発で「友達」クラスを使用する

通常、C ++では、ゲームの開発速度はカプセル化よりも重視されます。そのため、実際には公開すべきではない、公開されている大量のクラスメンバーが表示されます。

ほとんどの場合、ほんの一部のクラスだけが実際に別のクラスの内部動作を知って、それらのプライベートデータを変更または読み取る必要があることがわかります。

このプライベートデータのパブリックゲッター/セッターを作成すると、本当に変更してはならないことがすぐにわかります。

ここでの妥協は、友達クラスを使用することでしょうか？または、私が見ない友達クラスにいくつかの欠点がありますか？

友だちのクラスには2つの大きな欠点があります。

1. 友達に公開するものを選択することはできません。それは全部か無かです。ある種の重要ではないセッターを強制的に使用させようとしている場合、これは問題となる可能性があります。
2. あなたの2つのクラスは、友人が友人について知っているという意味で、いくらか結合されています。

そうは言っても、フレンドクラスを使用すると、特に代替がパブリックゲッター/セッターの場合は、カプセル化を確実に改善できます。

また、SOに関する関連質問：https : //stackoverflow.com/questions/521754/when-to-use-friend-class-in-c

カプセル化は優れていますが、懸念の分離はより優れています。

他のクラスの「一部のプライベート部分」にアクセスするクラスは、コードが最初からうまく設計されていないことを示している可能性があります。

「ああ、ここで友達クラスを作る必要がある」というスポットに出くわすたびに、「私はこれを正しくやっているのか、それとももっときれいな方法があるのか​​」と自問する必要があります。（別名「これは後でお尻に噛み付くのですか？」）。

「親しみやすさ」が確かなら、迷わずそこに置いてください。

別のオプションは、構造の実装の一部が別の型へのポインターであるPIMPLイディオムを使用することです。クラスのほとんどのユーザーは、実装が不透明なポインターである通常のヘッダーファイルをインクルードするだけです。プライベートデータへのアクセスが必要なクラスには、他のタイプを定義するヘッダーを含め、それが提供するインターフェイスを使用できます。

これは、友人のような機能を必要とするCプログラマにとって一般的なパターンです。私の意見では、カプセル化（懸念の分離を実装するのに役立つが、誤用されることも多いOO固有の手法）ではなく、懸念の分離（一般に優れた設計原則であり、再利用可能な直交コードにつながる）について考えることにも重点を置いています物事を複雑にするには）。

これは、友達よりも友達-eをまったく結びつけないという点で友達よりも優れています。誰もがあなたのクラスを「友達」にすることができるので、何人かの人々はそれが不利であると主張するかもしれません。（ヘッダーを含めることによって）関係を明示的にしているので、それは不当な恐れだと思います。あなたがそれを恐れているなら、あなたはあなたの（またはあなたの同僚の）賢い建築決定をする能力を恐れています。しかし、後でこれらの決定を適切に行うことができない場合、なぜfriend今自分を信頼しているのですか？

これには、実行時のコストという欠点があります。ポインターにデータを格納すると、キャッシュの一貫性が低下し、割り当て数が増えます。また、データをクリーンアップするためのデストラクターも必要です。