Nsryjdtyk

I often find myself in a situation where I need to have a lot of objects as parameters for a method, but all or almost all of those objects can be referenced from another object. In my case, I've got loads of objects such as particle managers and projectile managers which are all attributes of a screen object. Sometimes I just give the entire screen object as the parameter to save time, getting whatever objects I need.

Is this good practice or not? On the one hand, it saves me time, but I don't know the impact of the extra (unnecessary) information also within the screen object when I send it as an argument. Is this inefficient?

So you have a Screen object that has lots of useful fields that your other methods need, and you are too lazy to pass those fields to those methods, so you made the methods all accept a single Screen object, then you can just pass your Screen.

Hopefully I have understood your situation correctly.

This doesn't actually mean that you are moving unnecessary data around in memory. Objects themselves aren't copied when they are passed as parameters. Only their addresses are copied, which would be the same size of data as if you pass the individual fields. Addresses are all of the same size. Therefore, this probably won't cause a performance problem.

However, this might be bad design. By passing Screen to your methods, you are making your methods dependent on Screen. If your methods has nothing to do with the UI, they should not depend on Screen, right? They should work without a Screen as well.

Also, your Screen might be a god class and break the Single Responsibility Principle. You might want to refactor that.

It's hard to say in general. Adding an extra parameter means an extra push on the stack, which is generally compiled down to... an extra push on the stack. So regardless of whether it's running in interpreted mode or in compiled mode, you will have one more push per call. But that's fairly cheap. By comparison, getting that same object by making another method call or just dereferencing a variable, could be fast or it could be a little slower - it depends on what happens to be in the L1 and L2 caches at the time, which could vary from call to call. But either way, the object is never copied (unlike in C++). So in summary... it depends, and you probably shouldn't worry about it too much in general. First profile your code if it's slow, and focus only on the parts of the system that are much slower than they could be.

To me, passing a single context - this is how I call that "transfer" object, is appropriate. As said, if you want to support future additions or removals of some parts of that object - this is easy to do.

But there are cases when I am only pro-passing separate individual pieces. This is the case when you want to test a method and if some more objects are needed for a method - I want tests to fail.

 // context contains first and second

 public void testMe(Context context) {



 }

vs

 public void testMe(String first, String second){



 }

Adding one more parameter to the context, like String third - will most probably make your test pass; but adding one more parameter to a method that expect two... It's easy to ignore writing a unit test, it's a lot harder to ignore a compilation error. So sometimes, we have code that takes more arguments for this reason.

As far as performance, I doubt you will ever feel a difference (even if one exists), after all, passing objects is actually passing a reference.