2

I read that a class is like a blueprint for an object. So is it considered bad practice to declare a class but then in the program, never actually create instances of the class (but just have static methods in the class)?

hungryghost
  • 9,463
  • 3
  • 23
  • 36
noobProgrammer
  • 467
  • 3
  • 8
  • 20

3 Answers3

8

I would say that in object oriented programming the use of statics should me minimized, but they do have a place. It takes a bit of time to develop a good sense for when static methods/variable are appropriate, so I would start out only using them in a small set of circumstances where they are encouraged and then expand your usage as you gain experience. To list a few of appropriate uses:

In any discussion about the use of statics it is worth discussing dependency injection and writing testable code, as these principles discourage the use of global state which is often a side effect of things being declared static.

Community
  • 1
  • 1
cyber-monk
  • 5,470
  • 6
  • 33
  • 42
3

If you have a class that won't have any state associated with it (meaning no instance variables), then it's fine to have all static methods. An example is a simple utility class that encapsulates behavior you would need in every DAO, like closing db connections, statements and result sets. I do this with every project I create.

You want to be careful with static methods, though, because they can't be overridden and they can be difficult to test in some scenarios.

pyetti
  • 188
  • 2
  • 14
-2

Static considered a very bad practice due to several reasons

  • it is very hard to test
  • you will very fast find urself changing values and not knowing where did that " magically happened"

The bigest problem with static classes is that you cannot mock them , and that means that you cannot test the code that uses them in a good way , Someties there is a need for utility classes , but it is itself considered a smell , since in the SOLID principles a class should have its responsibility , and by creating a utility (general) class you break the "single responsibility princple"

Also the static principle has nothing to do with a language but with the OO princples themselves.

there are huge amount of articles

and enough on the SO itself

Community
  • 1
  • 1
Dan Kuida
  • 1,017
  • 10
  • 18
  • 1
    "*The bigest problem with static classes is that you cannot mock them*". Know your tools, use e.g. [PowerMock](https://code.google.com/p/powermock/). – Turing85 Jun 11 '15 at 00:13
  • 1
    @Turing85 it is important to know and have tools , but can you write such a mock by hand ?easily ? especially for a beginner the best way to learn about mocks is trying to write by hand to realise why you need tools – Dan Kuida Jun 11 '15 at 00:14
  • "you cannot mock them , and that means that you cannot test them". Isn't it more like "you cannot test code that uses them"? You aren't testing the code you are replacing with a mock, you are testing some other code that (normally) depends on that code. – Thilo Jun 11 '15 at 00:17
  • Yes, PowerMock can mock static stuff by messing around with the classloader and e.g. confusing the hell out of code coverage tools like Jacoco. Not good IMHO. Only using it for third party stuff, would always refactor my own code to make it testable without the need to get the big tools out. – Jan Groth Jun 11 '15 at 00:19
  • "Static considered a very bad practice due to several reasons". I can't agree and would caution anyone against taking this advice to heart. Static utility classes are well-established in Java and can not be considered an anti-pattern. Also, static member classes should be favored over inner classes whenever possible. Moreover, there are situations when immutable objects can be presented as static fields. – scottb Jun 11 '15 at 00:32
  • 1
    All this is only true if the class has mutable state. Many classes don't, and that's totally fine: java.lang.Math, java.until.Collections, a zillion guava classes like Sets, UnsignedLongs, etc etc – yshavit Jun 11 '15 at 00:33
  • @yshavit: Not true. Even without mutable state, you may want to override implementation methods (to do something else). That cannot be done with static methods. If Collection.sort was an instance method on List, you could supply an alternative sorting algorithm to go along with your data. – Thilo Jun 11 '15 at 07:49
  • Ok, true. I should have said "mostly," not "only." Even in your case, though, ypu could just as easily accomplish that with a strategy object. – yshavit Jun 11 '15 at 12:16