4

So I know how to reference variables from different classes, but I'm wondering if it's worth me creating a Vars.class to house all my global vars.

This would make it easier for me if I need to change them at a later date however, I'm wondering if this is a bad idea speed wise? Does it take longer to reference a var from a different class?

Thanks

EDIT: When i say 'global variables', I meant 'global constants'. Apologies for the confusion. I want them to be referable from other classes, but they will not be changed on the fly.

Vars.java

package test;

public class Vars
{
    static int variable1 = 16;
    static int variable2 = 32;
}

Start.java

package test;

public class Start
{
    public Start()
    {
        int i = Vars.variable1;
    }
}
StewDMill
  • 43
  • 4
  • 7
    Global variables are a bad idea! You should not need global variables. Not because of performance reasons, but because your source code will become a ball of spaghetti that's hard to understand. – Jesper Sep 27 '12 at 11:33
  • your code in start class wouldnt compile – PermGenError Sep 27 '12 at 11:34

5 Answers5

7

So I know how to reference variables from different classes, but I'm wondering if it's worth me creating a Vars.class to house all my global vars.

No. It's worth trying to avoid having global variables in the first place. Variables should represent the state of a particular object - so group variables according to sensible boundaries for useful objects, and then make sure that each object knows about whatever other objects it needs to depend on.

There's little point in using an object-oriented language if you're going to throw away object orientation.

Taking the time to work out the appropriate types in your application will no doubt be slower in the very short term than just having global variables... but it'll make your code much easier to maintain and test.

As for performance: you're worrying about that much too early. Access time for variables will almost never be a significant performance impact. Design your code in the simplest way that works. Decide on a performance metric and acceptance criteria. See whether your code already meets those criteria. If it doesn't, work out why it doesn't and perform the cleanest change you can to improve performance (measuring all the time).

Additionally, the variables themselves should almost always be private: storage is an implementation decision; consider how and whether to expose the state through methods.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 2
    ...and wondering if it imposes a performance penalty is the conceptual basis for premature optimization http://stackoverflow.com/questions/2978460/practical-rules-for-premature-optimization – TheBlastOne Sep 27 '12 at 11:37
  • @TheBlastOne: Thanks, I missed the performance aspect. Will add that in. – Jon Skeet Sep 27 '12 at 11:39
  • I've edited my post due to my failure to explain properly. Is your reply still valid after the edit? – StewDMill Sep 27 '12 at 11:59
3

Global variables are a bad idea. Thre are lots of articles on the web about them. This is a good one

If you want to handle global constants

eg

public static final Integer MY_CONSTANT = 1;

then I would still put the constant in the class it is related to. I would not personally set up a variables class. Try and keep you code encapsulated so the variables are as close to there use as possible.

RNJ
  • 15,272
  • 18
  • 86
  • 131
2

The answer is No.. If you have think about the security then there are no functional drawbacks.

Chathuranga Chandrasekara
  • 20,548
  • 30
  • 97
  • 138
0

Global variables are bad idea.

This would make it easier for me if I need to change them at a later date however

Maybe you need constants? It makes sense to have all constants in one place, if you think you will need to change them. Use use public static final for constants:

package test;

public class Constants
{
    public static final double EPSILON = 0.001d;
}

package test;

public class Start
{
    public Start()
    {
        ...
        if(arg1 - arg2 < Constants.EPSILON)
        ...
    }
}
bigGuy
  • 1,732
  • 1
  • 22
  • 37
0

I prefer keeping constants close to the class or classes that use them. No catch-all objects; no interfaces.

If objects or values are required by lots of objects, I'd think about injecting them with a DI factory.

If the values change, I'd think about putting them in a database and accessing them as configuration.

Anything but what you've proposed.

duffymo
  • 305,152
  • 44
  • 369
  • 561