views:

83

answers:

5

Given the below setup and code snippets, what reasons can you come up with for using one over the other? I have a couple arguments using either of them, but I am curious about what others think.

Setup

public class Foo
{
    public void Bar()
    {
    }
}

Snippet One

var foo = new Foo();
foo.Bar();

Snippet Two

new Foo().Bar();
+3  A: 

If you are not going to use the Foo instance for more than simply doing that call I would probably go for the second one, but I can't see that there should be any practical difference, unless the call happens extremely often (but that does not strike me as very likely with that construct).

Fredrik Mörk
This is one element I was eluding to. Is there any functional differences? Does the GC have an easier time getting rid of one over the other?
Ty
Might be instructive to examine the IL emitted in each case.
AakashM
I doubt that the GC will find one of them harder to deal with than the other; that probably depends more on what you choose to do with the reference that you store in the first example.
Fredrik Mörk
The GC doesn't care when it's not debugging. It may care when running in a debugger - I suspect it will hold on to all "genuine variables" until the end of the method or at least their scope.
Jon Skeet
@AakashM: I did a check of emitted IL code, and the only difference I can see there is pretty much the same as in the code; in the first there is a local variable created, and the reference to the Foo instance is stored in it.
Fredrik Mörk
A: 

I would favour the second as it makes it pretty clear that I don't need the object reference at all.

flq
A: 

I'd question your motives for having this as a instance method. If I'd only new up the object to call one method on it and discard it afterwards, a static method with the classes dependencies as parameters should be the way to go (although I despise statics).

What leads to the more interesting problem: If you don't rely on internal state at all, then you are just a function and therefore I'd say you belong to some entity, not in your own class.

Tigraine
This example came out of working with an XmlSerializer, so the structure of the class is already established and is what it is. Just trying to see what others preferences were wrt style.
Ty
+9  A: 

The first version means you can examine foo in a debugger more easily before calling Bar().

The first version also means you associate a name with the object (it's actually the name of variable of course, but there's clearly a mental association) which can be useful at times:

var customersWithBadDebt = (some big long expression)
customersWithBadDebt.HitWithBaseballBat();

is clearer than

(some big long expression).HitWithBaseballBat();

If neither of those reasons apply, feel free to go for the single line version of course. It's personal taste which is then applied to each specific context.

Jon Skeet
Really good points.
Fredrik Mörk
A: 

I'd go for snippet number one.

If you're going to have class Foo do Bar() then Bar2() it will be easier.

Plus its easier to debug because you can watch foo, something that you can't with snippet 2

Eric