commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@gmail.com>
Subject Re: [compress] Draft 6
Date Fri, 12 May 2006 15:51:36 GMT
On 5/12/06, will pugh <willpugh@sourcelabs.com> wrote:
> Hmm.
>
> Factories have always seemed most useful to me when they are
> encapsulating the creation of some configurable resource.  In practice,
> it seems like "configurable" most often means pulling a string from some
> attribute or properties file, and using that to choose implementation.
>
> If the type of Archiver I am using is static and would never change, I
> would simply the Archiver's constructor.  If it's not static and will
> change, you are almost always going to have to deal with a string at
> some point.  Passing that string into a factory is easier than getting
> this ZIP member via reflection (and cleaner than special casing every
> Archiver type)

FWIW: Reflection isn't needed for the valueOf method. the method just
looks in an internal Map or Set for the requested type.

> Sandy McArthur wrote:
>
> > On 5/12/06, Torsten Curdt <tcurdt@apache.org> wrote:
> >
> >> > here is a new draft:
> >> > http://www.grobmeier.de/commons-compress-draft-6.zip
> >> >
> >> > 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?
> >>
> >> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg79370.html
> >
> >
> > 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.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


-- 
Sandy McArthur

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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message