カップリングが高すぎたり、このようにデザインしても大丈夫ですか？

Question

私はclassAを持っているとしましょう。そのフィールドには独自のフィールドがあり、カプセル化の基準に準拠していますか？それから、私はの最後の状態（classAの方法のうちの1つによって得られ、ややカプセル化を破る）をその実行のために必要とするclassBを持っています。そして、私たちはclassCを持っています、そしてそれは再び最終状態classBを必要とします。そういうことで、classMに言います。それはあまりにも高い結合かどうかと考えられていますか？

編集：私は、敵が敗北した（それぞれの敵は異なる落としのチャンスを持つ）ために落ちるかどうかによってLootシステムを設計していたとしましょう。敵が倒れた場合、クラスハンドリングの戦闘は、何かを落とすかどうかにかかわらず、サイコロを振って、その状態を戦利品の配布を扱う他のクラスに伝播する必要があります。ドロップがある場合、クラス処理ルートは、ルーツの生成とプレイヤーへの配布を実行します（そうでない場合は無効）。その上

classA a = new classA; 
... //classA does its stuff 
classB b = new classB(a.getFinalState()); 
... // again class does its stuff based on outcome of A 
classC c = new classC(b.getFinalState()); 

そして：

最終実行は次のようになります。

Answer 1

編集：あなたはすでに示唆したように、Delegation Patternとの密接な兄弟Decorator Pattern

Builderパターンに従うことによって、あなたが望むものを達成することができる、有効な代替です。それはいつもオリジナルのデザインが何を目指しているかにかかっています。

Answer 2

はい。レベル2との密接な結合があります。これは避けることができ、コードの柔軟性と再利用性を低下させる悪い習慣とみなされます。そしてテストは夜の牝馬です。

相互に関連するプロパティを持つ場合は、Builder Patternを参照してください。

ビルダーパターンがコンストラクタアンチパターンは、あなたがこれまで持っているものであることを伸縮式コンストラクタアンチパターン

への解決策を見つけることです。