Should we create objects if we need them only once in our code?

Question

This is a coding style questions:-

Here is the case

Dim obj1 as new ClassA

' Some lines of code which does not uses obj1

Something.Pass(obj1) ' Only line we are using obj1

Or should we directly initiaize the object when passing it as an argument?

Something.new(new ClassA())

Answer 1

If you're only using the object in that method call, it's probably better to just pass in "new ClassA()" directly into the call. This way, you won't have an extra variable lying around, that someone might mistakenly try to use in the future.

However, for readability, and debugging it's often useful to create the temporary object and pass it in. This way, you can inspect the variable in the debugger before it gets passed into the method.

Answer 2

Generally speaking, I would say no, there's nothing wrong with what you're doing, but it does sound like there may be some blurring of responsibilities between your calling function, the called function, and the temporary object. Perhaps a bit of refactoring is in order.

Answer 3

Your question asks "should we create objects"; both your examples create an object.

There is not logically any difference at all between the two examples. Giving a name to an object allows it to be referred to in more than one place. If you aren't doing that, it's much clearer to not give it a name, so someone maintaining the code can instantly see that the object is only passed to one other method.

Answer 4

I personally prefer things to be consistent, and to make my life easier (what I consider making my life easier may not be what you consider making your life easier... so do with this advice what you will).

If you have something like this:

o = new Foo();
i = 7

bar(o, i, new Car());

then you have an inconsistency (two parameters are variables, the other is created on the fly). To be consistent you would either:

• always pass things as variables
• always pass things created on the fly

only one of those will work (the first one!).

There are also practical aspects to it as well: making a variable makes debugging easier.

Here are some examples:

while(there are still lines in the file)
{
    foo(nextLine());
}

If you want to display the next line for debugging you now need to change it to:

while(there are still lines in the file)
{
    line = nextLine();
    display(line);
    foo(line);
}

It would be easier (and safer) to have made the variable up front. It is safer because you are less likely to accidentally call nextLine() twice (by forgetting to take it out of the foo call).

You can also view the value of "line" in a debugger without having to go into the "foo" method.

Another one that can happen is this:

foo(b.c.d()); // in Java you get a NullPointerException on this line...

was "b" or "c" the thing that was null? No idea.

Bar b;
Car c;
int d;

b = ...;
c = b.c;   // NullPointException here - you know b was null
d = c.d(); // NullPointException here - you know c was null    
foo(d);    // can view d in the debugger without having to go into foo.

Some debuggers will let you highlight "d()" and see what it outputs, but that is dangerous if "d()" has side effects as the debugger will wind up calling "d()" each time you get the value via the debugger).

The way I code for this does make it more verbose (like this answer :-) but it also makes my life easier if things are not working as expected - I spend far less time wondering what went wrong and I am also able to fix bugs much faster than before I adopted this way of doing things.

To me the most important thing when programming is to be consistent. If you are consistent then the code is much easier to get through because you are not constantly having to figure out what is going on, and your eyes get drawn to any "oddities" in the code.