• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

static method or non-static method?

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear guys,

I have a doubt regarding whether I should use static method whenever possible or non-static method? The thing is, in order to call a non-static method, I need to instantiate an object. And if an object is no longer being referenced, it gets disposed by the garbage collector. So, I get the feeling that the more instantiated object the more workload for the garbage colector. Is it means that the program's performance is lessen?

Thank you for your time.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Aji Prasetyo:
So, I get the feeling that the more instantiated object the more workload for the garbage colector. Is it means that the program's performance is lessen?


In theory. In practice, this is never an issue since it is such a small percentage of performance.

Also there is a tradeoff because the more static things you have, the more that needs to be in memory. Basically, code the method type that makes sense without respect to memory.
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Static or Non-Static.

It is a question that should be answered by the design which should be based on the requirements. As far as possible refrain from static methods unless and until your design need your object to be a singleton or you need to have a class level attributes / methods.

Reasons:
1) If you are not cautious you may end up losing integrity. Having class level attributes and using static methods to access them with out proper synchronization.
2) Static methods / variables are against OO principles. It is another way of implementing global access in the procedural languages.

This is from my experience. Please correct me if I am wrong.
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by vijay vv:
...
2) Static methods / variables are against OO principles. It is another way of implementing global access in the procedural languages.

This is from my experience. Please correct me if I am wrong.


I beg to differ.

In principal, static methods are not against OO, but they can be abused to do so.

It's hardly a choice of memory or similar.
It is a choice of design.

imho it boils down to this: Is the method in question part of the class, or part of an object?
 
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Indeed. Static data is not very object-orientated and should be avoided where possible. This design issue is more important, in 99.9% of applications, than any tiny performance difference between static and non-static.
 
Aji Prasetyo
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am surely blessed by your answers. I am learning alot. Thank you so much.

One more thing, in practice for-instance I have a class named Master. Inside Master I have an inner class called InnerMaster. The innerMaster need a variable mVariable from Master. In this case should I make the variable static or not?



thank you.
 
Peter Chase
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Depends whether you want mVar to have a single value for all Master instances, or a separate value for each Master instance.

That's a design question, not a performance question, of course.
 
Mladen Grabowsky
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

One more thing, in practice for-instance I have a class named Master. Inside Master I have an inner class called InnerMaster. The innerMaster need a variable mVariable from Master. In this case should I make the variable static or not?


Of course it has to be static, or you wn't be able to access it.

static as such is not bad and certainly not "not ObjectOriented", it just depends on the usage, nothing else.
 
Peter Chase
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mladen Girazovski:
Of course it has to be static, or you wn't be able to access it.



Sorry, that's just plain wrong. One can access outer class instance variables from a non-static inner class.

In the original poster's class, the inner class is non-static, so it can access static and instance variables of the outer class.

Originally posted by Mladen Girazovski:

static as such is not bad and certainly not "not ObjectOriented", it just depends on the usage, nothing else.



I disagree here, too, but in this case it is a subjective opinion. An application with a lot of static methods is not a good object-oriented design - it's procedural. Static methods prevent overriding and polymorphism, which are key to object-orientation.

Some Web references: -
1
2
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mladen Girazovski:

Of course it has to be static, or you wn't be able to access it.



That's simply not true, the following should compile fine:

 
Mladen Grabowsky
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Peter,

Sorry, that's just plain wrong. One can access outer class instance variables from a non-static inner class.

In the original poster's class, the inner class is non-static, so it can access static and instance variables of the outer class.


In the example given, no object reference was used, only the class itself, and in this case, the member would have to be static.
I agree that my statement was too general, but so is the statement "that's just plain wrong".

I disagree here, too, but in this case it is a subjective opinion. An application with a lot of static methods is not a good object-oriented design - it's procedural. Static methods prevent overriding and polymorphism, which are key to object-orientation.


I can agree that an application with lot of static methods could be somewhat misdesigned, however, there is the need for static methods to implement some design patterns, (Abstract)Factory etc.

Those patterns are certainly object oriented, saying that static is always not OO enough is too general imho.

Thanks for the links, i enjoy reading them, however, they do not state that static is in general bad, it says "might not be conforming well to object oriented design principles...".

While what you've said about polymorphism and overriding is of course true, is doesn't mean that static is always bad (i keep repeating myself..), there is use for it, how else would you model a property or method that does not depend on an object but rather on the class?

Ilja, please see what i wrote about the object reference in the example given.

Regards,

Mladen
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mladen Grabowsky said it best:

Is it part of the class, or part of an object?

Lets say I have a Dog class, and a run() method - the run method works on an instance of the Dog class - it's part of the object, therefore would not be static.

If I have a Service class called MailService, that has a sendMail(String emailAddress) method - I would probably make it static, because we're not acting on an instantiated MailService object, but we're using the class as a place to put code that deals with sending messages.

Lets reverse it - lets say Dog.run() was a static method - we would have to pass it a reference to a Dog object, for example:



as opposed to:

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,

I have this view. If you desagree please let me know:

I have a web application (made in Java of course) with its web interface; and other java projects for the logic layer, validation layer and the data layer. For the web interface I use non static methods because you simply can't force the infrastructure to work as a static.

Then I write all skeleton code in the logic, validation and data layer as a static, for instance: static createEntityA, static validateEntityA, static persistEntityA... and so on.

The method above (createEntityA) is called directly from a crud Servlet, then each method is calling the next layer (up to down)

Finally I have the Transfer Objects. They are all instantiable classes, and they are created by the Servlet, then it passed them to the static method createEntityA, and so on...

I saw in the jProfiler test that the JVM does not invoke its GC so frequently as if all classes were instantiables (the logic layer, data layer, validation layer, etc) because for each request the application has to instantiate each layer class, and when the request is finished those classes remains for the GC.

So, what do you think about this design??

PS: This is the useful forum of Java.
reply
    Bookmark Topic Watch Topic
  • New Topic