Thoughts on generics for Codec I tried an approach to add generics to Codec here: https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
I consider this (now old) experiment part success and part failure and I would like to share it here. I will call this experiment the ‘single type’ approach. In this experiment I use one interface called Encoder<I,O> and one called Decoder<I,O> such that one class can implement a Codec by implementing both Encoder and Decoder. In the branch, the following interfaces support generics: · Decoder<I, O> · Encoder<I, O> The branch adds interfaces that respectively subclass each of the above: · SymmetricDecoder<T> extends Decoder<T, T> · SymmetricEncoder<T> extends Encoder<T, T> The following interfaces subclass their respective symmetric interfaces: · StringEncoder<String, String> · StringDecoder<String, String> · BinaryEncoder< byte[], byte[]> · BinaryDecoder< byte[], byte[]> The main problem with this approach is that -- because Java’s current implementation of generics performs type erasure at compile time -- a class can implement exactly one Encoder and one Decoder. In Codec 1, we have many classes that cannot fit in such a scheme, because we encode and decode to multiple types, like String and byte[]. This explains the different sets of classes in this branch. Class Changes *BinaryCodec* is now abstract and you must replace it with one of its subclasses: *BinaryByteCodec* or *BinaryCharCodec*. Option: We could leave this class concrete. *Hex* is now abstract and you must replace it with one of its subclasses: * HexByteCodec* or *HexCharCodec*. Option: We could leave this class concrete. *QuotedPrintableCodec* is now abstract and you must replace it with one of its subclasses: *QuotedPrintableBinaryCodec* or *QuotedPrintableCharCodec*. Option: We could leave this class concrete. *URLCodec* is now abstract and you must replace it with one of its subclasses: *URLByteCodec* or *URLCharCodec*. Option: We could leave this class concrete. The abstract class names are not prefixed with Abstract for less ugly code that use static method. We should move these static methods to their proper subclasses, further breaking compatibility. Method Changes The Encoder and Decoder interfaces now implement generics. This means that there no longer is encode and decode methods that take and return *Objects*. Call sites must use the proper type, like *String*, *char[]*, or *byte[]*. Next Upon reflection, it seems overly restrictive (thanks to Java) to have one encoding or decoding type per class. What should be the alternative for a nice OO design? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
