Re: Java and OO Concepts

Joe Pluta skrev:

Thorbjoern Ravn Andersen wrote:

I was actually wondering myself when I wrote it but could not crystalize out a reason then.

And I disagree (not violently <grin> but I do disagree).

Feel free. As I am also gathering my experiences on a usually-one-man-seldom-two team with lots of legacy code, I'm using all other means possible to sharpen my skills and my mind. That includes this list :)

It is basically my personal experience in what gives the least resistance in the long run, where I have reached that conclusion.

And in my personal experience, while I don't use double and float for the reasons you've stated, Thorbjørn, I prefer to use int for true integer values. However, I don't find a whole lot of integers in the real world; primarily counts. If Java had a true fixed precision primitive, I would use it all the time, and this would be a bigger issue.

In this case with an item count, what would you use then?

What type do you give monetary values (and how do you handle currencies)?

Primitive types are not objects so they cannot be subclassed if different behaviour is needed. They cannot be used as parameters to methods expecting an object (like slf4j which I use a lot), and ALWAYS require special treatment everywhere. They cannot have a descriptive toString method!

I don't think this is a good reason to add the overhead of an Integer. Unless I'm mistaken, you can turn anything into String by just coding ""+intValue. And class variables don't need toString; that's the job of the containing class.

Depends on your needs. You can always for non-final classes make an anonymous class at assignment overriding the toString method providing better information (which is making a class for that single instance). That might be extremely helpful for post-mortem debugging with variable dumps.

But again, this is more of a personal opinion. I just try to avoid extra overhead whenever possible. I'm not saying you should spend all your time optimizing your code, but it's my personal belief that the performance problems with some Java applications come from a complete disregard of performance issues, and unnecessary objects are just one more straw on the performance camel's back.

My personal opinion is that the JVM's these days support "plain Java" very well. Small methods are inlined. Garbage collectors are optimized to deal with lots of short lived objects. Classes are compiled to binary code unless redefined when they go back to interpretation and potential recompilation. The price: Memory usage unfortunately.

In my experience those Java applications which still have performance problems, do so to an algorithm which scales badly (sort cards? Throw them in the air and see if they fall down sorted, if not do it again), building extremely large data structures, doing work on the event thread, or doing much more than just one thing :)
What have you found the usual performance problems to be and how did you fix them?