ほとんどのオブジェクトへのポインタを保持するクラスを持ち、それを介してオブジェクトを参照するのは悪い習慣ですか？

Question

私の最初の大きなプロジェクトにはかなりのコンポーネントがあります。そして、クラスが異なる複数のオブジェクト間でやりとりが必要になったとき、重要なオブジェクトすべてへのポインタを保持するStateクラスを作成することにしました。コンストラクタを使用して新しいオブジェクトに渡します。オブジェクトにアクセスするには、私はいつもstate.object.method（）;に行きます。私はまた、これを使って、同時に実行しているときに2つの状態オブジェクトを持つことによって、クライアントからサーバーを分離します。

私は専門家のプログラマーではありません（まだ:)）、私は物事のプログラムの構造を気にして、それを "正しい"方法で構築していますが、私はこれを見ていませんどこか他の。これはまともな構造ですか？それとも私はまだ見ていないいくつかの問題はありますか？私は正しいOOの方法で考えていないのですか？

これが正常な方法であれば、私は穴の問題は主観的になり、ここで議論するべきではないと思います。もしそうなら、私はすみません。

構造について心配しているコーダー。

Answer 1

オブジェクトのコレクションを管理することによって、アプリケーションの「状態」を処理する種類のマネージャオブジェクトを作成しました。

このマネージャへの参照（アプリケーションのシングルトンに近い）は、アプリケーションオブジェクトのコンストラクタに渡されます。これは、ひねりを伴った一種の依存関係注入を作成します。つまり、実際の依存関係は、使用時に余分な間接参照によって取得されます。

これは良いデザインであるかどうかは、アプリケーションモデルに大きく依存していると思います。パブリックメンバーの代わりに、ゲッターメソッドを使用してリファレンスを取得し、オンデマンド作成のオプションを提供します。

アプリケーションの参照が構築時点から安定している場合（つまり、マネージャが保持するオブジェクトはアプリケーションのライフサイクル全体にわたって変更されません）、オブジェクトを取得するために渡されたマネージャ参照を使用するようにクラスを変更できますそれらを使用してオブジェクト参照属性を初期化する必要があります。

最も最適なデザインの多くは、アプリケーションの基礎となるモデルによって異なります。注目すべき点は、静的な定義、オブジェクト間の依存関係の作成、オブジェクトのオンデマンド作成とアプリケーションの初期化時の作成、オブジェクト間の参照数などのライフサイクルのプロパティです（マネージャがアプリケーション内の他のオブジェクトあなたが私たちに与えた情報に基づいて、あなたのデザインは悪い習慣ではないと思っています（コードベースに常に改良を加えることができます。リファクタリングを "あなたのコードに「完璧」なのです）

Answer 2

それぞれのクラスが依存するすべてのオブジェクトが渡される場合は、依存関係注入を使用する方がよい場合があります。通知/公開の状況では、Observerパターンまたはリスナー・パターンを使用できます。コンポーネントはブローカにデータをパブリッシュし、リスナーはそのデータをリスニングします。これらの2つのモデルを使用すると、状態を6個未満のオブジェクトに切り捨てるか、完全に削除することができます。