On 29 April 2013 03:21, Gary Gregory <garydgreg...@gmail.com> wrote: > 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? > > The "nice design" needs to be nice to use as well, so any discussion of changes to the API needs to consider how the user code will look.
Are there any particular aspects of the current design that are awkward to use? If so, how will the new design solve these? Will the new design produce awkard edges of its own? 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 >
