I prefer immutable classes because they are threadsafe, can't be changed by the template designer, and follow Joshua Bloch's advice in the book Effective Java (an excellent read, BTW).
I find myself creating wrapper classes for specific Generic types of collections in Java 1.5. Those who have not tackled Generics in JAVA 1.5 (or JAVA 5.0) will not appreciate the following explanation very much. A wrapper class (call it MapList<K,V>) for Vector<SimpleMap<K,V>> is a lot handier that writing Vector<SimpleMap<K,V>> when I use this particular formulation a lot and pass it to the template designers. It is also easier for my template designers to use MapList<K,V> than trying to understand the intricacies of Generics in JAVA when the specification gets complicated. I can also have methods that are more straightforward and return objects that are automatically cast to the proper class. VERY handy. Even for commonly used, less complicated collections, using a wrapper is sometimes nice. For example, I have a wrapper for HashMap<String, String> that is immutable and comes in handy for storage as a web session attribute. It's the only way I can retrieve something that acts like HashMap<String,String> from a session attribute, since you can't cast to a class-with-Generics in Java 1.5. In my case, it avoids a lot of warning:unchecked compilation messages in my web applications. Probably more than you wanted to know. Despite writing extra classes (but not many) and a lot of frustration having to sort out what Generics can and cannot do, in the end I think they are a BIG plus for developers who can adapt. Barbara Baughman X2157 On Tue, 19 Oct 2004, Shinobu Kawai wrote: > Hi Barbara, > > > Actually, I was trying to create a class that was immutable, which > > means I wouldn't want to implement Collection. If I have the class > > just implement Iterator would that do it? > A bit off topic, but would one of the Collections#unmodifiable* > methods work for you? > http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html > I mean, you wouldn't want to re-implement a fully tested function > already supplied in java, do you? > > Best regards, > -- Shinobu Kawai > > -- > Shinobu Kawai <[EMAIL PROTECTED]> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
