Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
In my program design, I often come to the point where I have to pass object instances through several classes. For example, if I have a controller that loads an audio file, and then passes it to a player, and the player passes it to the playerRunnable, which passes it again somewhere else etc. It looks kind of bad, but I don´t know how to avoid it. Or is it OK to do this?
EDIT: Maybe the player example is not the best because I could load the file later, but in other cases that does not work.
As others have mentioned, this isn't necessarily a bad practice, but you should pay attention that you're not breaking the layers' separation of concerns and passing layer-specific instances between layers. For instance:
However, if the instances you're passing are the DTOs or entities themselves, it's probably ok.
Interesting that no one has talked about Immutable objects yet. I would argue that passing an immutable object around through all the various layers is actually a good thing rather than creating lots of short lived objects for each layer.
There are some great discussions of immutability by Eric Lippert on his blog
On the other hand I'd argue that passing mutable objects between layers is bad design. You're essentially building a layer with the promise that surrounding layers won't alter it in a way to break your code.
Passing object instances around is a normal thing to do. It reduces the need for keeping the state (i.e. instance variables) and decouples the code from its execution context.
One issue that you may face is refactoring, when you must change signatures of multiple methods along the invocation chain in response to changing parameter requirements of a method near the bottom of that chain. However, it can be mitigated with the use of modern software development tools that help in refactoring.
Maybe minor, but there's the risk of assigning this reference somewhere in one of the layers potentially causing a dangling reference or memory leak later on..
If you are passing objects around simply because it's needed in a remote area of your code, using the inversion of control and dependency injection design patterns along with optionally an appropriate IoC container can nicely solve problems regarding carrying object instances around. I've used it on a medium-sized project and would never again consider writing a large piece of server code without using it.
Passing data trough a bunch of layers isn't a bad thing, its really the only way a layered system can work without violating the layered structure. The sign there are problems is when you are passing your data around to several objects in the same layer to achieve your goal.
Quick Answer: There is nothing wrong in passing instances of objects. As also mentioned, point is to skip assigning this reference in all the layers potentially causing a dangling reference or memory leaks.
In our projects, we do use this practice to pass DTOs (Data transfer object) between layers and it is very helpful practice. We also do reuse our dto objects to construct more complex once, like for summary information.
I'm primarily a web UI dev but it sounds to me like your intuitive discomfort might be less about the instance pass-through and more about the fact that you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?
In OOP design, I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.
In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.
So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works. And that's ultimately the biggest OOP design win to shoot for, IMO.
It's quite a common design that ends up happening although you might have latency problems if your app is sensitive to that sort of thing.
This problem can be solved with dynamically scoped variables, if your language has them, or thread-local storage. These mechanisms let us associate some custom variables with an activation chain or thread of control, so that we don't have to pass these values around into code that has nothing to do with them just so that they can be communicated down to some other code which does need them.
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:
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.
What you are describing is a called a Chain Of Responsibility design pattern. Apple uses this pattern for their event-handling system, for what it's worth.
