Static methods can access static fields of the class. You can pass the parameters to the method when you are invoking the method or you can access the static fields of the class. Anyways, you need to carefully design your classes.
You might consider using Enums. As a matter of fact there is an example along the lines of what you are trying to do in the java tutorial pages.
Take a look here and scroll to the bottom and look at the planets example.
Isaac Davis wrote:I'm extremely confused on the use of static methods. I've been writing a code to calculate the surface gravity of each planet in our solar system. I got help from my teacher and I thought I understood but when I tried to finish the program I was still very confused. I know the problems somewhere in the main method and the static void method printResults. The main problem I'm really having is referencing things. I'm not sure how to tell another method to grab info from the main method and print that out. I'm just really confused, any help or refernce to a good static method tutorial or anything that will help will be appreciated.
I think there's more confusion here than over static methods; however, static is what you asked about, so I'll try to explain it first.
You define a class with, among other things, methods and variables. You can declare, among other things, that either the methods or the variables are static, or not. A static item is associated with the class, not an object of the class.
One simple example made of them is a counter for the whole program. Let's say you wanted to define a class called "Planet" (which, incidentally, I think might be a good idea here), and for whatever reasons you wanted to keep track of how many planet objects got instantiated. You could start with:
While I was at it, I've tried to illustrate what I was thinking about in terms of other things you might want to know.
The Planet class defines those things that you might want to know about a planet -- in particular, its mass and diameter as stored values, and the knowledge of how to calculate a few other things. One advantage of OO design and coding is that the things that are associated with planets are in this class -- it helps you know where to look for them later. Also, if you decide you want to store things about the luminosity, orbital period range, or whatever, then you know where to put those things and the methods needed to support them.
We instantiate as many planets as we want; we can put them in an array like you did with your values.
The variables in Planet are mostly "instance" variables, which is the counterpart to "static". You define them in the class, but they only have values if you create an instance of the class, and then their values refer only to that instance. So you instantiate the class once per planet you intend to deal with. I have made one instance of the class for the planet Mercury. You would not want the methods which return values for one planet to be declared 'static', because they refer to one instance of the class; getDiameter, etc., are methods you would not want to be static.
The static variables exist whether you have instantiated the class or not, and their values are not associated with an instance of the class; the 'objectCount' variable in my example will go up each time you instantiate the class, and you could print it out as well if you wanted to. So getObjectCount needs to be static because it is referring to a variable that is associated with the class, not with one instance of the class.
The 'g' variable is likewise usable whether you have made an instance, and I have also declared it "final" meaning that it cannot be changed by the program (which just helps to catch program bugs).
There are things I did not create variables for -- radius and surface gravity can be calculated using mass and diameter for any planet, so there's no great need to have it in a variable.
The only two remaining items in this little example are the Planet constructor, which I hope is self explanatory, and the 'main' method itself. If you think about it, you may be able to figure out why 'main()' has to be static -- whatever runtime code it is that starts up your main method cannot know how to construct an object of your class -- it doesn't know what parameters to pass or anything. So it needs a way to get your code executing without knowing that, and so main methods are static.
You may have noticed one anomaly in this example (well, at least 1); the length of the sol array pre-determines how many planets you can have and how many your results printout loop expects. Another topic for another time would be Java collection objects, which allow you to do things like create as many planet objects as are indicated, even if that changes at runtime, and keep them in a collection of Planet objects that does not have to have its size fixed when you are writing the program. But in case you noticed the anomaly and wondered about it, this is how you might address that limitation in a bigger program.
I hope if there's still something you want to know, you can ask a specific question or two, or perhaps this will give you enough to plow through one of the standard texts.
Or: If a method has no use at all of any of the instance fields, consider making it static.