Managerクラスを作成しないようにするにはどうすればよいですか？

XxxManagerゲームエンジンプログラミングでスタイルクラスを使用することは悪い考えですが、使用を避けようとしても、常にすべてのアクター/エンティティ/ゲームワールドの場所を保持し、それらに作用するものになります。Manager別の名前ではifになります。

これは本当に悪いパターンですか？もしそうなら、選択肢は何ですか？

「マネージャー」クラスは、さまざまな理由で問題になる可能性があります。2つの主な理由は次のとおりです。

• 名前は不明確です（実際に「管理」とは何を伴いますか。また、管理対象のすべてのタイプで常に同じですか？）
• 彼らは、単一の責任原則に違反する機能のバケツになる傾向があります（つまり、型は1つのことをする必要があります）

多くの場合、これらの理由の1つが他の原因を引き起こしたり暗示したりします。

これらの問題は心に留めておくべき良いものですが、実際にあなたの能力を麻痺させてはいけません ゲームを作成する。最終的に、誰もあなたのクラスが何と呼ばれ、何をするか気にしません。彼らはあなたのゲームを気にします。

通常、ほとんどの「マネージャー」を2つの部分に分けるのは非常に簡単です。

• 実際のオブジェクトを格納し、それらへのアクセスを提供する部分（「ストア」、「リポジトリ」、「データベース」、「キャッシュ」、またはその他のさまざまなものと呼ぶことができます。これは通常、責任を負うタイプです。オブジェクトの存続期間、つまり、オブジェクトがこのタイプのインスタンスから削除されるか、このタイプのインスタンスに含まれなくなると、オブジェクトは存在しなくなります。

• 実際のオブジェクトを処理し、それらに対して何らかの作業を実行する部分。これらのオブジェクトを更新する場合（「アップデータ」または「シミュレーション」）または描画する（「描画」または「レンダラー」）場合があります。または、彼らと何か他のことをするかもしれません。重要なことは、その主な目的に応じて名前を付けることです。通常、このタイプのインスタンスには、最初のタイプ（オブジェクトのライフタイムを処理するだけのインスタンス）のインスタンスまたはインスタンスへの参照を与えます。

最初のタイプの名前にmanagerを含めることができるという合理的な議論を行うことができます（一部のオブジェクトの「存続期間を管理する」ため）。このようにタイプに名前を付けても、世界は終わらないでしょう。ただし、「マネージャーに電話しないでください」という形式のひねりの反応にかなり頻繁に耐える必要があるかもしれません。

コメントでリンクしたブログ投稿を読むと、「別の名前の場合はマネージャーになっている」ということがまさにあなたが望んでいることがわかります。ソフトウェア開発では、グローバル変数は悪であるという一般的なコンセンサスがあり、唯一の選択肢はデータが他のデータによって保持されることです。

という名前のクラスの問題は、FoobarManager「マネージャー」という言葉がクラスが実際に何をするかを教えてくれないことです。例えば：

• foob​​arsのゲームメカニクスを制御する場合、名前を付けることができます FoobarController。
• foob​​arsをインスタンス化するが、制御を他の何かに委任するFoobarFactory場合、またはFoobarBuilderです。
• foob​​arsを画面に描画すると、 FoobarRendererです。
• foob​​arsによって生成されたイベントをリッスンすると、 FoobarEventHandlerです。
• フーバーで何かが起こるのを待つとき、それは FoobarObserverです。
• ロジックがまったくないfoobarのコレクションの単なるデータホルダーである場合は、名前を付けるだけです Foobarsです。

これらのクラスに「Manager」という名前を付けることができます。しかし、その後、これらの機能のいずれかを実行できます。また、上記の機能のうちの別の機能が必要であることに気づいたら、それをFoobarManagerに統合します。そのため、懸念の分離の原則を破る神のオブジェクトになります（すべてのクラスが1つのことを行う必要があります）。