commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject Re: [compress] Draft 6
Date Fri, 12 May 2006 15:08:58 GMT
On 5/12/06, Torsten Curdt <> wrote:
> > here is a new draft:
> >
> >
> > I have changed a lot of things discussed with draft 5.
> > The API is easier now. Everything what seems to be unnecessary has been
> > deleted. Compress is working with Files and InputStreams only, no more
> > String-params are allowed. New is also ArchiveEntry, which represents
> > the entry of an archive ;-).
> >
> > For example, a zip file can be created like this:
> >
> > Archiver archiver = ArchiverFactory.ZIP.getInstance();
> Why not use a proper factory? Did you consider my suggestions?

At Draft 3 or 4 I suggested he use a type safe enum for an
"ArchiveType" which fully implemented would have implicitly had the
factory feature built in and can remain extendable. eg:

ArchiveType someType = ArchiveType.valueOf("zip")
Archive someArchive = someType.newInstance();

the small problem with that or any factory is the use of a String to
request a behavior means the compiler cannot know for sure if that
code will work. The enum solves this if the programmer wants by having
the constants. If the compiler allows the following you know it work:

Archive zip = ArchiveType.ZIP.newInstance();

That said, it's better to commit to one idiom. Chris, as long as you
have the ball on this you gotta pick the suggestions that work well
together from all the feedback. On the surface the "ArchiveFactory"
Factory/Enum hybrid seems to be less good than just using either a
factory pattern or an enum pattern alone.

Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message