Class vs Local instantiation

Question

Is there a difference in class and local instantiation when the first one is not obligatory (usually when i can finalize them)? Is there a "rule" i should follow?

I have developed the habit to always instantiate other classes using class instantiation and i don't really know if this is bad.

public class aService {
    private final SomeClass someClass = new SomeClass();

    public void someMethod() {
        someClass.doSomething();
    }
}

// or

public class aService {
    public void someMethod() {
        SomeClass someClass = new SomeClass();
        someThing.doSomething();
    }
}

it depends on what someClass is and does. Is there any state on it, or is it immutable ? — Amir Afghani, Oct 03 '16 at 16:50
It's not exactly the same, but when it makes no difference, then the first version is better, because you only have to create the object once per object and not once per method call. — maraca, Oct 03 '16 at 16:50
The *significant* difference between these two is that, in your first example, you'll have access to a variable called `someClass` in all scopes, whereas in your second example, `someClass` disappears as soon as `someMethod` finishes executing. Is it the case that you're asking your question about the lifecycle of that variable? — Makoto, Oct 03 '16 at 16:50
@Makoto if we say that the someClass is not used by multiple methods but only once and does not need to be scoped, should i prefer the local instantiation? — pror21, Oct 03 '16 at 16:55
btw you might also have a look at the `static` keyword (once globally instead of once per object). — maraca, Oct 03 '16 at 16:55

score 0 · Answer 1 · answered Oct 03 '16 at 16:52

I would prefer initialize someClass in given method if it is used only in that method.

If you want to use someClass across all methods (more than one) and store object state, then choose solution 1.

First approach is better when you want optimization, because someClass is created only once. On the other hand, you may never call someMethod(). In this case you waste memory. Especially if you have lot of such objects

score 0 · Answer 2 · answered Oct 03 '16 at 16:57

0

If the situation you describe is a single-use method which is instantiated once to serve a specific purpose, after which its instance does not need to exist anymore, then I would prefer neither of these options. Both create an instance unnecessarily.

Instead, I'd rather focus on making the method that I care about in SomeClass static. The chief reason is that I can save an unneeded instantiation of an object and make the API and its usages a lot smoother.

answered Oct 03 '16 at 16:57

Makoto

104,088
27
192
230

That's an interesting way. Static maybe is what i was looking for. – pror21 Oct 03 '16 at 17:02
And potentially much harder to unit test. I think static should be used only when there are very good reasons to do so. – GhostCat Oct 03 '16 at 17:04
@GhostCat so what you would do? – pror21 Oct 03 '16 at 17:34
I say: A) avoid **static** where possible B) for your question: you only make those things a field of your class that more than one method needs. – GhostCat Oct 03 '16 at 18:40
@GhostCat: A perfectly legitimate usage of `static` is one in which the state of the referred class isn't implicitly required. It shifts the unit test from focusing on the result of the method at the return level to the result of the method based on its side effects, which doesn't make it that much more difficult to test. If you don't need the instance of the class, then `static` is the more ideal solution. – Makoto Oct 03 '16 at 18:57

score 0 · Answer 3 · answered Oct 03 '16 at 16:58

There is no "rule" per se, but as it is related to development the rule is related to good clean developer code guidelines... calss fields/ variables should be initialized in the constructor... that is the constructor's job.

constants can be declared and init in the same line for obvious reasons...

Class vs Local instantiation

3 Answers3