Question about static methods.
[133 byte] By [ssv45324a] at [2007-10-2 17:54:52] 
Is there any other advantage of using static methods, other than the reason that it is not required to instantiate the object?
Not really. Modern JVM's are good enough that the overhead of object creation is negligible. On a touchy-feely level, static methods normally encourage developers to write stateless methods. This can be a good thing (in say a service layer) or a bad thing (in say the model domain).
- Saish
Saisha at 2007-7-13 19:13:23 >
> Is there any other advantage of using static methods,
> other than the reason that it is not required to
> instantiate the object?
I use them when defining interfaces (general definition not java definition) to simple subsystems.
In particular I always prefer the the first example below to the second.
Logger.error("Something is wrong")
Logger logger = ....
logger.error("Something is wrong")
jschella at 2007-7-13 19:13:23 >
You should not talk about advantage to use static method... If requirement needs it , then u should use static method....
System.out.println............ It should be static. as you really do not need an instance to print something in the screen... Because there could be only one existence of Systm object ....
redwina at 2007-7-13 19:13:23 >
I use static method where ever possible (ServiceLayer, Utils, ...)No instantiation makes code easy and friendly.This is in my opinion a very good advantage.So currently i can't see any reasons, to use it only, when requirement needs it.
hammouda at 2007-7-13 19:13:23 >
> You should not talk about advantage to use static
> method... If requirement needs it , then u should use
> static method....
>
> System.out.println............ It should be static.
> as you really do not need an instance to print
> something in the screen... Because there could be
> only one existence of Systm object ....
This is incorrect.
There is no System object, only the System class. It is not instantiable.
There could, however, be more than one, if it were written that way.
But that's irrelevant, and System has nothing to do with it. It's not System.println. It's System.out.println. out is a PrintWriter, and it would be wrong for println to be static because there can obviously be many PrintWriters.
jverda at 2007-7-13 19:13:23 >
> I use static method where ever possible
> (ServiceLayer, Utils, ...)
> No instantiation makes code easy and friendly.
> This is in my opinion a very good advantage.
>
> So currently i can't see any reasons, to use it only,
> when requirement needs it.
Using static methods like that makes code very non-OO, and will lead to a development and maintenance nightmare for all but the smallest, simplest programs.
jverda at 2007-7-13 19:13:23 >
> Using static methods like that makes code very non-OOIf classes do not have attributes, just only service methods, why using objects?> lead to a development and maintenance nightmarePlease give me examples - where, why?
hammouda at 2007-7-13 19:13:23 >
> > Using static methods like that makes code very
> non-OO
> If classes do not have attributes, just only service
> methods, why using objects?
Of course.
But if you're using an OO language like Java, it's probably because you will be using objects. If you're not, then either you've got a messed up design, or you've probably chosen the wrong tool for the job.
jverda at 2007-7-13 19:13:23 >
> If you're not, then either you've got a messed up design, or you've probably chosen the wrong tool for the job.
I ask for examples/arguments to your post and you write such a answer:(
Of course i use objects - all application layer work with objects.
I be very astonished, that you even think its possible without.
> Using static methods like that makes code very non-OO, and will lead to a development and maintenance nightmare
I still miss examples or arguments which would substantiate your statement.
hammouda at 2007-7-13 19:13:23 >
> Of course i use objects - all application layer work
> with objects.
> I be very astonished, that you even think its
> possible without.
You said: I use static method where ever possible. To me, that sounds like you seldom use objects and actively try to avoid doing so, and when you do create objects, that you pass them around as data, rather than calling instance methods on them.
> > Using static methods like that makes code very
> non-OO, and will lead to a development and
> maintenance nightmare
>
> I still miss examples or arguments which would
> substantiate your statement.
If you just have a bunch of static methods all over the place, you're basically using Java as a procedural language. This is not how Java was intended to be used, and it's not what people maintaining the code will expect to see. Furthermore, it suggests a lack of understanding of how to use the tool, which is probably a good predictor of other poor practices.
jverda at 2007-7-13 19:13:23 >
> To me, that sounds like you seldom use objects and actively try to avoid doing so
Oh now is see - no that is a missunderstanding.
If i build a class i think about: Is it really neccessary for me or other programer to build an object before someone can use it.
If its not neccessary static use its much more comfortable, code becomes easier.
(belongs not to classes for storing data)
>, and when you do create objects, that you pass them around as data, rather than calling instance methods on them.
Hm - don't understand - data classes?
What should be bad creating objects and passing them to other layers or scopes.
> Java as a procedural language
Hm - no/yes - cant agree to 100%
Data classes - no question is OO
But the application flow - is step by step - always kind of procedural
If i look to web application:
Request -> Controller -> Logic (+Persistenz) -> View
Also all is done in objects think this is procedural
hammouda at 2007-7-13 19:13:23 >
If i build a class i think about: Is it really neccessary for me or other programer to build an object before someone can use it. If its not neccessary static use its much more comfortable, code becomes easier. (belongs not to classes for storing data)
To me that sounds like a description of someone using Java as a procedural language, and confusing objects with data structures.
There are certainly places for static classes (Math is a good example) but they're more the exception than the rule.
That's not to say that you can't write a perfectly useful program in Java using procedural techniques - it's just that it's sort of missing the point.
My oil on the flames...
dcmintera at 2007-7-13 19:13:24 >
> >, and when you do create objects, that you pass them
> around as data, rather than calling instance methods
> on them.
>
> Hm - don't understand - data classes?
> What should be bad creating objects and passing them
> to other layers or scopes.
It's not bad in and of itself. But from what you said earlier, it sounded like you go to great pains to avoid non-static methods, so I wondered if, rather than foo.doStuff() you would maybe call FoosClass.doStuff(foo). That would be a poor use of Java.
jverda at 2007-7-13 19:13:24 >
> To me that sounds like a description of someone using Java as a procedural language, and confusing objects with data structures.
And to me it sounds like you are afraid to use static method:)
> foo.doStuff() you would maybe call FoosClass.doStuff(foo)
No - look which one is nicer
instance:
Foo foo = new Foo();
foo.doStuff();
static:
Foo.doStuff()
Don't you use service, action, controller or call it what you will, which executes an special event step by step like:
1. create article
2. create articleitems
3. display new article list
This is procedural if you run it in an instance of ActionClass or static in the ActionClass.
I always want to learn more and also it's no problem for me to switch to other coding concept.
But you have to bring arguments and not only something like "This is bad, this is non OO, ..."
Where is the advantage!
> My oil on the flames...
Thats absolut desired - i like good discussions!
hammouda at 2007-7-13 19:13:24 >
> And to me it sounds like you are afraid to use static
> method:)
I'm certainly cautious about their use. They hint at poor design. Excessive use of them is a "code smell".
> No - look which one is nicer
It depends if there are side-effects from calling doStuff(). If so, then the first (dynamic) form is certainly preferable.
> But you have to bring arguments and not only
> something like "This is bad, this is non OO, ..."
Without specific examples, it's hard to be sure if you're doing it right or wrong! But the way you describe it is suggestive of procedural thinking.
> Where is the advantage!
Of OO design? It lies in coding in a way that better matches our cognitive model, making code easier to understand, design, and write.
The disadvantage of procedural coding is that it results in a disconnect when you attempt to use OO code (such as the standard libraries), and gives you performance baggage without the concomitant advantages.
Which you're doing, however, is unclear.
dcmintera at 2007-7-20 23:25:39 >
> > foo.doStuff() you would maybe call
> FoosClass.doStuff(foo)
> No - look which one is nicer
> instance:
> Foo foo = new Foo();
> foo.doStuff();
>
> static:
> Foo.doStuff()
This is completly different from what I was talking about, and you seem to have missed the point.
> I always want to learn more and also it's no problem
> for me to switch to other coding concept.
> But you have to bring arguments and not only
> something like "This is bad, this is non OO, ..."
> Where is the advantage!
I'm not going to give you a bunch of arguments on the advantages of OO programming. They can be found easily in a textbook or web search. I assume if you're using Java it's at least in part because you know the advantages of OO and want to take advantage of them.
Bottom line--if you're modeling a real world concept that can be represented as state and behavior, then create an instance of the corresponding class, give it the desired state, and call its non-static method. If not--for pure functional stuff, for utility and "manager" classes, where distinct objects' state and behavior don't make sense, use static methods.
However, going out of your way to make something static just to avoid creating an object is the wrong approach. You're letting laziness about typing drive your design.
jverda at 2007-7-20 23:25:39 >
> Of OO design? It lies in coding in a way that better matches our cognitive model, making code easier to understand, design, and write.
And maintain.
Yes, I know that's probably covered in "understand, design, and write", but I felt it important enough to mention... :o)
yawmarka at 2007-7-20 23:25:39 >
> You should not talk about advantage to use static
> method... If requirement needs it , then u should use
> static method....
>
Excluding systems that were specifically defined using a specific interface I haven't seen any requirements that required static.
jschella at 2007-7-20 23:25:39 >
> > To me, that sounds like you seldom use objects and
> actively try to avoid doing so
>
> Oh now is see - no that is a missunderstanding.
> If i build a class i think about: Is it really
> neccessary for me or other programer to build an
> object before someone can use it.
> If its not neccessary static use its much more
> comfortable, code becomes easier.
> (belongs not to classes for storing data)
But if most of your classes follow that model then most of your classes are not OO objects.
jschella at 2007-7-20 23:25:39 >
> > To me that sounds like a description of someone
> using Java as a procedural language, and confusing
> objects with data structures.
>
> And to me it sounds like you are afraid to use static
> method:)
>
>
> > foo.doStuff() you would maybe call
> FoosClass.doStuff(foo)
> No - look which one is nicer
> instance:
> Foo foo = new Foo();
> foo.doStuff();
>
> static:
> Foo.doStuff()
The point is not which one is easier.
My previous example with Logger is based on the following actual usage of "logging"
1. There are two types of users.
2. The two types do not mix.
3. The vast majority of users will only want to use only the post type of operation. This leads to the simple static interface to the sub-system.
4. The much smaller group of users that might want to do something else with logging will be using the objects of the sub-system. They will not be using the static interface.
Because of the above, I choose to implement Logging as I do.
Conversely if I have something like "Account" then it isn't going to have any static methods.
jschella at 2007-7-20 23:25:39 >
Think you all missunderstand.
Don't want to hear advantage/arguments about OO - thats clear.
> This is procedural if you run it in an instance of ActionClass or static in the ActionClass.
Therefore i want to here your advantages.
What is the advantage to create instance and than call the method of this instance instead of calling a method static.
If its neccessary, like in JSF Framework or some special desired behaviour - ok
But otherwise not static way is much more better.
> But if most of your classes follow that model then most of your classes are not OO objects.
Don't agree - sorry but all here write this statement without any arguments.
And in my opionion util/service classes with only static method follows also OO (capsulation).
Static is just part of Java - so just use it if you can.
> cautious, side effects
Why? If you use only non shared attributes or method variables, side effects could not occur!
Quite the converse: other programers see static and know immediatly, that they can use it without instantiation and all variables are declared right.
So just keep this in mind:
- Instance method rely on state of specific object/instance
- Static method belongs to the class and not to the instance
=> Every method which is independent of instance state is candidate for static
hammouda at 2007-7-20 23:25:39 >
The notion that you "can use something without instantiating," as if creating an object is somehow burdensome or to be avoided, completely misses the point and strength of OO programming.
jverda at 2007-7-20 23:25:39 >
> creating an object is somehow burdensome or to be avoided- if its not neccessary: yes- if code and usage gets easier: yes> completely misses the point and strength of OO programming.Must replay: just bring arguments to such statements
hammouda at 2007-7-20 23:25:39 >
Do I really need to give support for the idea that OO's strength and one of the main points for using it is how it allows (not requires, as if it were a bad thing) you to work with objects?
I'm not interested in providing you with that elementary education. If you find objects so repulsive, don't use an OO language.
jverda at 2007-7-20 23:25:39 >
> > creating an object is somehow burdensome or to be
> avoided
> - if its not neccessary: yes
> - if code and usage gets easier: yes
It has already been pointed out to you that it's not about "making it easier." You're just talking about saving a little typing. But that's a bogus advantage if the cost is that you're twisting your model to do so.
jverda at 2007-7-20 23:25:39 >
> I'm not interested in providing you with that elementary education. If you find objects so repulsive, don't use an OO language.
I do like objects very much - why do you imply this:(
But i also know how to use static.
I am not only one who uses static, see:
Sun: java.util.Collections, java.util.Arrays
JavaWorld: http://www.javaworld.com/javaworld/javaqa/2001-11/03-qa-1121-mrhappy.html
Think its better to stop here this discussion.
I find it just boring to speak with somebody, who talks about incorrectness the whole time and also i ask serveral times for, he is not able to bring any argument:((
So just do it in your way - instances are also correct.
Leave discussion definite,
good night
hammouda at 2007-7-20 23:25:39 >
> I do like objects very much - why do you imply
> this:(
Because you have stated that you use static whenever you can, and have spoken as if the main reason you do so is because it "allows" you to avoid creating objects.
> But i also know how to use static
So do I.
.
> I am not only one who uses static, see:
> Sun: java.util.Collections, java.util.Arrays
> JavaWorld:
> http://www.javaworld.com/javaworld/javaqa/2001-11/03-q
> a-1121-mrhappy.html
Static methods have their place. The avoidance of creating objects, however, is not a good reason to use them.
jverda at 2007-7-20 23:25:39 >
> I use static method where ever possible
> But i also know how to use static.
The selection criteria for use of static is not "wherever possible".
> I am not only one who uses static, see:
> Sun: java.util.Collections, java.util.Arrays
The vast majority of the Java API is based on dynamic objects. Nobody's saying you shouldn't use static. We're saying that preferring it over dynamic objects isn't very object oriented.
> JavaWorld: (link)
Note that that link is making the same point I made earlier, when discussing your example doStuff() method. If doStuff has side effects (i.e. changes state) it's likely that it should be a dynamic method.
> I find it just boring to speak with somebody, who
> talks about incorrectness the whole time and also i
> ask serveral times for, he is not able to bring any
> argument
You've not come up with much of an argument yourself. "I'm doing it right" does not constitute an argument of much value. Actually I suspect you are - but it's not terribly clear.
> good night
Don't let the bed bugs bite...
D.
dcmintera at 2007-7-20 23:25:39 >
>
>
> > But if most of your classes follow that model then
> most of your classes are not OO objects.
>
> Don't agree - sorry but all here write this statement
> without any arguments.
> And in my opionion util/service classes with only
> static method follows also OO (capsulation).
> Static is just part of Java - so just use it if you
> can.
>
It has nothing to do with what java can do but rather what you do with it. C++ allows you to write entirely in C, but it doesn't follow that all C programs are thus OO programs.
Encapsulation is not the sole criteria for OO. A method in C entirely encapsulates the local variables of that method - do you claim that because of that C is an OO language?
>
> > cautious, side effects
>
> Why? If you use only non shared attributes or method
> variables, side effects could not occur!
> Quite the converse: other programers see static and
> know immediatly, that they can use it without
> instantiation and all variables are declared right.
>
>
> So just keep this in mind:
> - Instance method rely on state of specific
> object/instance
> - Static method belongs to the class and not to the
> instance
> => Every method which is independent of instance
> state is candidate for static
The discussion is not about the correct use of static methods. I am rather certain that everyone here understands how to use them.
jschella at 2007-7-20 23:25:39 >
> > I'm not interested in providing you with that
> elementary education. If you find objects so
> repulsive, don't use an OO language.
>
> I do like objects very much - why do you imply
> this:(
> But i also know how to use static.
>
>
> I am not only one who uses static, see:
> Sun: java.util.Collections, java.util.Arrays
> JavaWorld:
> http://www.javaworld.com/javaworld/javaqa/2001-11/03-q
> a-1121-mrhappy.html
Irrelevant. Statics have a use. No one claimed otherwise.
However....
1. Use statics unless it doesn't work.
2. Use non-statics unless it doesn't work.
Of the above two basic statements the second is what an OO programmer does where the first is what an new programmer with a procedural background does (I know because that is exactly what I did when I first started using C++.) It suggests that the programmer doesn't understant the point (theory) of OO and instead understands only the semantics of the language.
>
>
> Think its better to stop here this discussion.
> I find it just boring to speak with somebody, who
> talks about incorrectness the whole time and also i
> ask serveral times for, he is not able to bring any
> argument:((
> So just do it in your way - instances are also
> correct.
>
As pointed out there are numerous texts that explain the theory of OO. And we are not going to write a text explaining that theory along with the history that produced it.
jschella at 2007-7-20 23:25:45 >
> If you're not, then either you've got a messed up design, Or not done any design.
MartinS.a at 2007-7-20 23:25:45 >
seems confused to me. Given an example, i have a non-static class which incharge of talking to my Database, will it be inefficient if i use static method getData() when there is high concurrency access of the class?
can i say that static method means only have 1 method in the JVM regardless how many class instances i have in the JVM?
junecelloa at 2007-7-20 23:25:45 >
> seems confused to me. Given an example, i have a
> non-static class which incharge of talking to my
> Database, will it be inefficient if i use static
> method getData() when there is high concurrency
> access of the class?
"Efficiency" is NOT why one chooses static or non-static methods.
> can i say that static method means only have 1 method
> in the JVM regardless how many class instances i have
> in the JVM?
For both static and non static methods, only one copy of the method's code is loaded for the class. There is NOT a copy of the method's code for each obeject for non-static methods.
jverda at 2007-7-20 23:25:45 >
This is an interesting thread.
Is there any relation between using static methods all over the application and heap memory and garbage collection? Is it right to say, that the memory allocated by the static method operations are never get GC 'ed?
Message was edited by:
saran_v
saran_va at 2007-7-20 23:25:45 >
> Is there any relation between using static methods
> all over the application and heap memory and garbage
> collection?
No.
> Is it right to say, that the memory
> allocated by the static method operations are never
> get GC 'ed?
No.
I don't know what you mean by "memory allocated by the static method."
* If you mean memory used for the code that comprises the method's executable body, that is handled the same for both static and non-static methods. It's loaded when the class is loaded and there's exactly one instance for the whole class. As I mentioned above, non-static methods' code is NOT duplicated. The executable code is GCed only when the class is GCed, which only happens when the class is unloaded, which doesn't usually happen. You have to take pains to even make it possible.
* If you mean memory for objects allocated by new Whatever() inside the method's body, then again, no, what you said is not correct. It doesn't matter in what context an object is created. When there are no more reachable references to the object, the object is eligible for GC. For static methods, just as for instance methods, local variables and parameters go out of scope when the method completes. Therefore, if a local variable is the only reachable reference to an object, then when the method completes, that object becomes eiligible for GC.
jverda at 2007-7-20 23:25:45 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding