Re: Java and OO Concepts

Thorbjoern Ravn Andersen wrote:

Joe Pluta skrev:
In this case with an item count, what would you use then?

As usual in the business world, it depends. If this is a discrete count, such as light bulbs or battleships, you could use an integer. But as soon as you move into measured quantities (pounds, feet, whatever), you usually need decimal places. Another reason I say that integer counts aren't found all that often in the business world.

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

Money, units, etc., I use BigDecimal. For a while I used IBM's BigDecimal because it was a LOT faster, but I think recent versions of the core BigDecimal class have gotten better. Currency codes are a string.

And that's an interesting issue; I'm not big on using integers to represent strings. It's a lot easier to maintain your database when you're using real strings rather than codes. But then again, that's an RPG bias, since comparing a four character alpha field is roughly the same as comparing an integer.

In Java, string fields add overhead and have the extra pain of not being usable in switch statements. Ugh. You're getting me to explain all the reasons I *hate* Java for business programming <grin>.

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.

I don't use dumps a lot, so I'll take your word for it. In general, though, I don't do a lot of design based on how well the class dumps.

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.

No argument here, well written Java executes very well.

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?

The biggest problems come from people reusing code in ways it was not intended, or people modifying routines that are being reused. If you're not careful, OO can get layered dozens of layers deep and suddenly you have routines that are doing lots of gyrations when they don't need to be. There is no cure for that other than good, upfront design. And the worst case is developers use third-party routines that they don't really understand. Open source in particular can bite you in this regard, although at least with open source you can go in and find the issues, but that of course requires that you learn the intricacies of the open source code, which defeats at least part of the purpose of using third-party packages in the first place :).

Joe