There are two different uses for this in our code. It can be applied to methods or it can be applied to variables.
When static is applied, it disassociates the item being declared from any specific instance of the class. For methods, this means that the method can be called by anyone at any time without creating a new class of that type. This can be particularly handy for utility functions, initializers, or any other chunk of code that wants to run without caring that it's about a particular person, bill, or list of stocks. For variables, it mostly means that the value is shared across all instances of the class.
Static Methods
Static methods can be called without making a new class. For instance, it could be used for a factory method, which is a design pattern that calls for objects to be built by calling a function to do so.
public class Person {
...
public static Person createPerson(firstName, lastName) {
...
}
}
You can call createPerson without having a Person object, like so:
Person.createPerson("John", "Doe");
Many utility functions are declared as static, and as a general rule they will need to operate free of any context supplied by objects.
Static Variables
Static variables come from the same basic idea of being disassociated from any specific instances of the class. They're useful for maintaining overall context, for instance, if we want to keep track of how many Person objects we've created we could write something like this:
public class Person {
...
private static int numberCreated = 0;
...
public static Person createPerson(firstName, lastName) {
...
numberCreated ++;
...
}
}
Now, every time we invoke createPerson, we'll also be incrementing the value of numberCreated, and it will always be available as a statistic our programs can check.
Many times, inexperienced programmers will overuse static methods, because when they first start creating methods and functions, they just call them from main. Your main method has to be static, and if you try calling non-static methods directly from it, the compiler complains. So the path of least resistance is often seen as just making those other methods static too. This does seem to work, but it goes against object oriented design principals, and it's best to nip this in the bud. So they start with this:
public class OutputTest {
...
private PrintStream outputStream = ...;
...
public static void main(String [] args) {
print("This is a test");
}
...
public void print(String message) {
outputStream.println(message);
}
}
But that fails because you can't call 'print' from a static context, so they change it to this
public class OutputTest {
...
private PrintStream outputStream = ...;
...
public static void main(String [] args) {
print("This is a test");
}
...
public static void print(String message) {
outputStream.println(message);
}
}
That fails, too, because outputStream isn't static, so they change the code again:
public class OutputTest {
...
private static PrintStream outputStream = ...;
...
public static void main(String [] args) {
print("This is a test");
}
...
public static void print(String message) {
outputStream.println(message);
}
}
And they're satisfied. Everything works now! I call this the static cascade, and I recommend avoiding it. If you did not originally intend for these items to be shared and free of binding to specific objects, then don't go changing them to act that way.
Get used to writing object oriented code. Do this instead:
public class OutputTest {
...
private PrintStream outputStream = ...;
...
public static void main(String [] args) {
OutputTest test = new OutputTest(); //The key!
test.print("This is a test");
}
...
public void print(String message) {
outputStream.println(message);
}
}
While it might be a bit more of a conceptual leap, it's actually a far smaller change to the original code, and it opens your class up to being more adaptable to use in other systems. It's also a necessary step towards object oriented thinking, so you might as well get it over with now.
