-2

I am just checking my reasoning here, because I think I already know the answer. Someone asked me: No matter how many instances I might have of a particular class, a given method will surely have the same operation in each of those objects. So why have Java developers invented the static modifier for methods? We can contrast this with static variables. Here, of course, each object can have a different value for a given field.

My response was that, no, a given method will not have the same operation in each instance of the class. For example, setters and getters operate in "identical" ways in each instance of a class, but their output does depend on the instance of the class.

Rowan
  • 91
  • 3
  • 2
    Objects are state and behavior encapsulated together. Even if the methods are the same, each instance can have its own state. If those methods are operating on instance state they will behave differently. "Identical" is your mistaken assumption. – duffymo May 03 '17 at 09:10
  • 2
    Non-static methods only exist once, it is not as if each instance has their own copy of the method. Non-static methods just only operate on the instance they were invoked on. – Mark Rotteveel May 03 '17 at 09:13
  • @Rowan I upvoted because it a valid curiosity and this question is proof that you were giving it a thought and thinking about something which mostly others will just overlook. Kudos to you and all of us! who thinks and asks a question no matter what others will think. – Rishi Nov 03 '21 at 11:57

1 Answers1

7

Pretty broad question; but there are various simple facts to put up here: as static is regarded an abnormality regarding "good OO" principles:

  • static leads to direct coupling between different classes.
  • More importantly: there is no polymorphism with static methods. And polymorphism is the essence of OO programming!
  • And it doesn't only affect your code base; it can also make (unit) testing (much) harder.

In other words: you strive to not use static by default. There are cases where it makes sense; but you have to carefully consider those.

Or, giving my personal two cent: if static would be the "better answer", everybody would still be coding in Pascal and claim that imperative programming is the silver bullet of software engineering.

But to answer the "other" question here: "why do we need static at all then"?

Simply because it is convenient and helpful sometimes. When you turn to the java "system classes"; such as Collections or Objects you find a reasonable amount of "helpful" functionality there. And that allows to uphold other important properties of software quality; like: single responsibility principle. It makes sense that there is one central implementation of sort() for example; instead of having an "additiony" "can be sorted" behavior on collections directly.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • What do you mean exactly by methods being "called at compile time"? Methods are not actually called during compilation; the program has to be running for there to be any method calls. Did you mean _resolved_ at compile time? – Lew Bloch May 03 '17 at 16:15
  • "Invoked" is still not the right word and is merely a synonym for the incorrect "called". What's the difference between a static method invocation `Type.method()` and an instance method invocation `instance.method()`? Both are invocations. Both are present in the source. Both are compiled. Neither is actually invoked until run time. Methods simply are not invoked at compile time! – Lew Bloch May 03 '17 at 17:27
  • I couldn't find good words; so I simply deleted that last paragraph. Maybe I will have a better idea for tomorrow, but for now; I just dropped that part. So, in case that part is the reason for the one downvote I see ... the downvoter is welcome to undo his vote ... – GhostCat May 03 '17 at 18:31
  • I'm pretty sure the word you needed actually was "resolved". Static methods are resolved at compile time, overridable instance methods at run time. – Lew Bloch May 03 '17 at 20:25