Is the clutch too high or normally designed like this?

Question

Say I have a classA that has its own methods with its own private fields and what you have (basic compliance with encapsulation standards). Then I have classB , which requires the final state (obtained using one of the classA methods, which destroys encapsulation somewhat) classA . And then we have classC , which again needs the final state of classB . And so on and so forth, to say classM . Is this considered too high a connection or not?

Edit: Well, let's say I developed the Loot system, and it depends on whether the fall occurs on the basis of the defeated opponent (each opponent has a chance to lose a chance). If the adversary is defeated, the class processing the combat material will roll the dice, regardless of whether he rolls something or not, and then I need to extend this state to another class that processes the distribution of loot. If there is a fall, the class handling the loot generates a loop and spreads to the player, if not, void.

Final execution will look something like this:

 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()); 

And so on.

Answer 1

Edit: you can achieve what you want by following the Delegation Pattern and its close relative Decorator Pattern

Sample Builder, as already suggested, is a valid alternative. It always depends on what your original project aims for.

Answer 2

Yes. There is a tight link to level 2. This is very preventable and is considered bad practice, which reduces the flexibility and reuse of code. And testing is a night mare.

If they have interrelated properties, consider the Builder Pattern .

Sample Builder must find a solution for anti-telescope constructor template

This anti-pattern constructor is what you have.