[Deque]

Please do not forget that using the static variables could push to a bad designed applications. Use it only if you do not have any other choice, at least for simple applications. For example the information hiding principle becomes hard to be managed!

You shall not avoid static at all cost, you shall use it when it is applicable. That has nothing to do with having small or big applications. If you have a small application you should still create code that is reuseable, thus a class you can just take as is for another application.
An application that has non-static methods that aren't instance specific is as well bad designed.

An example is the factory pattern:

Code:

public class CarFactory { private static int numberOfCars = 0; public static Car createCar() { numberOfCars++; return new Car(); } public static int getNumberOfCars() { return numberOfCars; } }

None of these should be non-static.

Some examples of the Java standard library are:

Code:

Java: java.util.Collections.singletonMap() Java: javax.xml.parsers.DocumentBuilderFactory.newInstance()

[JDKlett]

Please do not forget that using the static variables could push to a bad designed applications. Use it only if you do not have any other choice, at least for simple applications. For example the information hiding principle becomes hard to be managed!

You shall not avoid static at all cost, you shall use it when it is applicable. That has nothing to do with having small or big applications. If you have a small application you should still create code that is reuseable, thus a class you can just take as is for another application.
An application that has non-static methods that aren't instance specific is as well bad designed.

An example is the factory pattern:

Code:

public class CarFactory { private static int numberOfCars = 0; public static Car createCar() { numberOfCars++; return new Car(); } public static int getNumberOfCars() { return numberOfCars; } }

None of these should be non-static.

Some examples of the Java standard library are:

Code:

Java: java.util.Collections.singletonMap() Java: javax.xml.parsers.DocumentBuilderFactory.newInstance()

Well, you are right. But don't you think that the abuse of these Class information could lead to some complexity later?

In this case you found a good solution for the problem but, for example, a disadvantage that I see is that you were forced to declare also the getNumberOfCar() method as static and that you are loosing a bit the concept of object (because to use this class you are not instantiating any object actually).

As long as you refer to well known approach as the design patterns I think it is all right. Another example could be the pattern singleton.

I think that you agree in the fact that care should be taken in the case you decide to attribute to the class a behaviour.

[Deque]

Well, you are right. But don't you think that the abuse of these Class information could lead to some complexity later?

In this case you found a good solution for the problem but, for example, a disadvantage that I see is that you were forced to declare also the getNumberOfCar() method as static and that you are loosing a bit the concept of object (because to use this class you are not instantiating any object actually).

As long as you refer to well known approach as the design patterns I think it is all right. Another example could be the pattern singleton.

I think that you agree in the fact that care should be taken in the case you decide to attribute to the class a behaviour.

I agree. *nods*
I also know that beginners tend to overuse static, but that's because they don't understand the concept of object orientiation at all and static helps them to avoid it.

[Deque]

Well, you are right. But don't you think that the abuse of these Class information could lead to some complexity later?

In this case you found a good solution for the problem but, for example, a disadvantage that I see is that you were forced to declare also the getNumberOfCar() method as static and that you are loosing a bit the concept of object (because to use this class you are not instantiating any object actually).

As long as you refer to well known approach as the design patterns I think it is all right. Another example could be the pattern singleton.

I think that you agree in the fact that care should be taken in the case you decide to attribute to the class a behaviour.

I agree. *nods*
I also know that beginners tend to overuse static, but that's because they don't understand the concept of object orientiation at all and static helps them to avoid it.

[JDKlett]

I perfectly agree. Static field are a powerful instrument, as long as you have a deep understanding of the oop.

[JDKlett]

I perfectly agree. Static field are a powerful instrument, as long as you have a deep understanding of the oop.

[Jacob]

Aside from using pictures and detailed explanation, a great way of stating the difference is simple:

Static objects share a universal instance and non-static do not.