「ResourceManager」クラスが不良と見なされる場合、代替手段は何ですか？

次のような相反する意見を聞いています。

• 「専任のマネージャークラスはほとんど適切なエンジニアリングツールではありません」
• 「専用マネージャークラスは（現在）何千ものリソースを持つ大規模プロジェクトを生き残るための最良の方法です」

次の機能を持つ従来のResourceManagerクラスを見てみましょう。

• アセット（テクスチャ、オーディオ、3Dモデルなど）をロードします
• キャッシュを保持することにより、アセットが一度だけロードされるようにします
• 参照は、資産を割り当て解除できるかどうかを判断するために資産をカウントします
• 実際の資産の出所を隠します（たとえば、資産ごとに1つのファイル、1つのパッケージファイル内のすべての資産、またはネットワークを介して資産をロードすることもできます）
• プログラムを再起動せずにアセットをリロードできます。これは、ゲームに取り組んでいるアーティストにとって非常に便利です。

また、これらのResourceManagerオブジェクトがシングルトンではなく、依存性注入を介して渡されるように見せることにより、テーブルから「シングルトンは悪い」引数を取りましょう。

次に、「ファクトリを使用する」または「ファクトリと呼ぶ」引数があります。これに関する私の問題は、はい、それはファクトリーですが、キャッシュとリローダーでもあるということです（より良い言葉がないため）。それをファクトリと呼ぶことはそれを適切に記述しません、そして私がそれを適切なファクトリにするならば、キャッシングとリロードはどこで実装されますか？

「マネージャー」クラスはしばしば悪いアーキテクチャの症状であることに同意しますが、この特定のケースでは、どのように再構築し、すべての機能を保持できますか？これは、「Manager」クラスが実際に適切な状況ですか？

問題は、これが悪い設計ではないことだと思います。問題は、「Manager」という名前が「Update」、「Process」、「Actor」などのように説明的でないことです。このシステムを理解しようとする人には役に立たず、資産に対して何らかの操作を実行する他のクラスがある場合は混乱を招きます。

しかし、目的を効率的に伝える方法で物事に名前を付けることは、本当に難しいです。ほとんどのシステムは複雑すぎて、名前で明らかにすることはできません。あなたができる最善のことは、これをクラスの凝集性にする特定のアイデアと、明らかに他のクラスを明らかにする必要があるものを絞り込み、そのような種類に合ったユニークな単語を選ぶことです。

私見、良い名前の最も重要な特徴は、人々がそれを見るコンテキスト（コードベース）内で一意であり、覚えやすいことです。テストは、あなたが言及していることを明確にすることなく、コードに精通しているチームメイトと会話できるかどうかです。これは、リファレンスドキュメントを作成する必要がある場合にも役立ちます。

最後に、まとまりのあるアイデアを説明できない場合、あまりまとまりがないかもしれないことを考慮してください。たとえば、AssetCacheでキャッシングと参照カウントを分離し、AssetLoaderで読み込みを保持できます。しかし、それは本当にコードがどれほど複雑で絡み合っているかにかかっています。

しかし、AssetManagerが十分にまとまっていて、ゲーム内でAssetManagery以外のものがなければ、それは完全に良い名前かもしれません。

「これを1か所で行うのか、それとも多数行うのか」

ロードロジックは、アプリケーションのキーポイントでのみ実行される傾向があるため、通常は単一のアクセスポイントに集中化されます。これは通常、アプリの起動時、ゲームレベルの起動時、またはプレイヤーのワールドポジションが新しいチャンクのロードを要求してエクスペリエンスをシームレスに保つときに行われます。これがバッチプロセスとして行われることを考慮すると（1つの巨大なチャンクであっても、多数の小さなチャンクであっても問題ありません）、1つのメソッドまたはメソッドセットを呼び出してこのプロセスを開始することは理にかなっています。

ほとんどのプラットフォームでは、ロードは非同期であるため、実際にはロードと他のアプリロジックのコードフローを分離する以外に選択肢がありません。これは、リソース管理機能を独自のクラスに抽象化するもう1つの理由です。

最後に、考慮すべきいくつかのポイント：

リソースの読み込みは、たとえば ゲームロジック、これを行うには個々のゲームオブジェクトに複雑さを追加する価値がありますか？通常、ゲームオブジェクトは可能な限り軽量に保ち、シミュレーション中に必要なもののみを対象としています。

オブジェクトは、それ自体の作成と破壊に責任を負うべきですか？これは、エンティティ管理中に大きな頭痛の種を引き起こす可能性があります。オブジェクトが独自の作成プロセス（リソースの依存関係の取得を含む）を実行することを期待する場合、同様にオブジェクト自体を破壊する責任があります。これにより、ぶら下がり/ヌルポインターが発生する可能性があるため、実際には外部から管理する必要があります。この問題の詳細については、この回答をご覧ください。

PS通常の「シングルトンはひどい」型の引数（ひどく教義的です）以外に、ResourceManagersに対して良い引数を見たことがありますか？「専用のマネージャークラスが適切なエンジニアリングツールになることはほとんどありません」は、この特定のケースではまったく議論されません。