As the other answers have pointed out, this is not an inherently poor design. It can create tight coupling between the nested classes and those that nest them, but loosening the coupling may not be a valid option if nesting the references provides a value to the design.
One possible solution is to "flatten" the nested references in the controller class.
Instead of passing a parameter several times through nested objects, you could maintain in the controller class references to all of the nested objects.
How exactly this is implemented (or if it is even a valid solution) is dependent on the current design of the system, such as:
- Are you able to maintain some sort of map of the nested objects in the controller without it getting too complicated?
- When you pass the parameter to the appropriate nested object, can the nested object recognize the parameter immediately, or was there additional functionality occurring while passing it through the nested objects?
This is an issue that I encountered in an MVC design pattern for a GXT client. Our GUI components contained nested GUI components for several layers. When the model data was updated, we ended-up passing it through the several layers until it reached the appropriate component(s). It created unwanted coupling between the GUI components because if we wanted a new GUI component class to accept model data, we had to create methods to update the model data in all of the GUI components that contained the new class.
To fix it, we maintained in the View class a map of references to all of the nested GUI components so that whenever the model data was updated, the View could send the updated model data directly to the GUI components that needed it, end of story. This worked well because there were only single instances of each GUI component. I could see it not working so well if there were multiple instances of some GUI components, making it difficult to identify which copy needed to be updated.