instantiating class without declaring variable

I'm used to instantiating objects this way,

MyClass myClass1 = new MyClass();

A co-worker tells me its ok to call a method of the class without instantiating as above, but by using

MethodReturnVariable myVariable = new MyClass().mymethod();

In this case, mymethod is a method of MyClass which returns MethodReturnVariable.

Is this valid? Can anyone explain what happens when this is done?

thanks

If you want to call an instance method of a class, then you must use an instance of the class to do it. In your first code, you are creating an instance of the class, and keeping the reference to it. In the second code, you are creating an instance of the class, but not maintaining the reference.

Yes that is valid. Some people do that when instance of MyClass is just used for mymethod() call and no other purpose. It create instance of MyClass object with no reference(so we can not use this object again) and calls mymethod on it.

If there is a finalize method in the class, when would it be called using both methods?

The code

is same as

In either case, the JVM creates an object of MyClass. In first example, you don't have a reference to that created object, where as in the later case, you get a reference to the MyClass object, which you can use it at a later stage, if necessary.

If I see lot of Style 1 in the code, I will consider it as a code smell, because you can use that style, only when you have throw away objects (meaning, the state of that object is not necessary), which is bad design, IMHO. If they are mere utility methods, then I would generally prefer to make those methods static and call them simply as

[ March 17, 2006: Message edited by: Mani Ram ]

If they are mere utility methods, then I would generally prefer to make those methods static ...

This answer is not wrong, but static methods have some limitations in flexibility. It might be worth keeping a real object and abstracting its creation:

Factory.getInstance().someMethod();

Now you've removed your hard coded dependency on the implementation class. Factory could return any subclass of MyClass, or better yet any implementation of MyInterface.

In the beginner forum I wouldn't recommend building this kind of flexibility all the time, but keep it in the back of your head somewhere. If you bump into something like that, figure out what kind of flexibility the author was trying to keep open. I know I've made a couple classes with all static methods that I regretted later because they were too hard to change.

Originally posted by Stan James:

This answer is not wrong, but static methods have some limitations in flexibility. It might be worth keeping a real object and abstracting its creation:

Totally agree. But this being a beginner forum & I was lazy to type a big explanatory post, I just skipped it

thanks for all of your input! this is a really great forum!

Originally posted by Mani Ram:
The code
//Style 1 MethodReturnVariable myVariable = new MyClass().mymethod();

is same as
//Style 2 MyClass myClass1 = new MyClass(); MethodReturnVariable myVariable = myClass1.mymethod();

In either case, the JVM creates an object of MyClass. In first example, you don't have a reference to that created object, where as in the later case, you get a reference to the MyClass object, which you can use it at a later stage, if necessary.

So it's not totally the same - in style 1, the object is eligible for garbage collection immediately after mymethod returned. In style 2, it is garbage collectible only after myClass1 gets out of scope.