• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why would we change a non static method to a static method.  RSS feed

 
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
Here is a silly one

I know that a non-static method does not require class instantiation.
But why would we opt for a static method. What is the main reason of not instantiating a class.

As per my knowledge, if a class loader is not available, one should opt for a static method (eg. Main method)

Any other reasons ??
 
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You CAN make a method static, if no attribute of the class is used.

A second rule is, that no non-static method of that class is used, which is in a recursive way the same question.

Sometimes you will mention, that your class doesn't use an attribute, so you may ask yourself: Shall I make this method static? I often learned something about my classes, when I mentioned such fact.

Beside main, there are some well-known static methods, which can help us understand their benefits.
I'm talking about:

We don't have an Integer-Object, we don't want one and we don't need one.
The Integer-class has this 'service'-method, we can use without an Integer.

Look into the javadocs, find more static methods, and answer yourself, why they are static.
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Static methods are particularly useful when you don't want to deal with object instances. For example, say that you have a system where you have a large number of objects that need to communicate with one another. Would you have each object hold a reference to each other object? What if there are 1001 object instances total? That's each of those objects holding 1000 references to other objects, or 1001*1000=1,001,000 references. That's a lot to manage.

Or, you could simply have them all agree to communicate through a mediator object that holds all the references to all the objects and passes the messages for you. And of course you only need one of those, so it could be static. But wait, you say, it doesn't *have* to be, does it?

Well, no, that too could be an instance...but even so you'd want to be sure there's only one of them, and that would require you to use the Singleton design pattern (a design that guarantees only one instance). So the object that holds the references could itself be non-static, but there has to be a reference to it somewhere that's accessible to all the other 1001 objects...where to put it? Following the Singleton pattern, the mediator object holds a static reference to an instance of itself, marks its own constructor private, and makes that reference available to everyone else via a static method:



Now, to be fair, one of the reasons you use the Singleton pattern instead of just making everything static is because static methods cannot be overridden, static variables cannot be inherited by subclasses...in other words, static stuff is not extensible. Neither is this class, with a private constructor...much better to make it a protected constructor so that it can be extended as Singletons are intended to be.

If you want a good exercise that will show you the need for static stuff, then write your own object pool (like a thread pool or DB connection pool). You'll quickly see the usefulness of class members and methods.

sev
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!