designing approaches ?

i have question in my mind ...is that suppose we are coding a big project so in that big project we have to create a lot of objects to access the methods of that class and all that
so now we have a lots of object in the heap .....so our GC is smart enough to remove the object from the heap when our machine is running out of memory ?
or alternativelly we declare every class static so that we dont have to create lots objects
i mean we can directly access the method with the class name of any of our class
which is the right designing approach ?

If you forbid to use objects, then there is no good usage of OOP. In my opinion, you have to concentrate on writing a good design based code which might include both creating objects and usage of static. I have ran into Out of Memory issues only due to my BAD coding and not due to creating numerous objects.

The garbage collector is much smarter than you think and normally there's no really good reason to worry about creating many (temporary) objects.

Having lots of static methods is generally a (bad) code smell.

Tim Moores wrote:Having lots of static methods is generally a (bad) code smell.

why can you explain ?
why they are bad

John Jai wrote:If you forbid to use objects, then there is no good usage of OOP. In my opinion, you have to concentrate on writing a good design based code which might include both creating objects and usage of static. I have ran into Out of Memory issues only due to my BAD coding and not due to creating numerous objects.

so what makes codes or our app slow ?
i mean i know a bad coding but what exactly a bad coding means ?

There's nothing bad about static methods per se, but if there are lots of them that's often a sign that the design is not very object-oriented (which is based on objects, not classes, after all) but rather in a procedural style (like languages of the Pascal family).

Tim Moores wrote:There's nothing bad about static methods per se, but if there are lots of them that's often a sign that the design is not very object-oriented (which is based on objects, not classes, after all) but rather in a procedural style (like languages of the Pascal family).

k thanks

I hit with OutOfMemory error when I tried to create a big XML concatenating small pieces of String. The idea is that you should not worry about handling of the objects by the JVM. You have to write a well designed and a good Object oriented code.

Things that may slow down your application will be in the way you code. There was a similar thread before two days I suppose which dealt with reading a File. Rather than reading full on the buffer size it was written to read by byte basis I suppose. If I find that thread I will post it here later.

I got that thread - these things you should be more wary of
http://www.coderanch.com/t/555021/java/java/Speeding-up-BufferedInputStream-FileOutputStream