commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From will pugh <willp...@sourcelabs.com>
Subject Re: [compress] Draft 6
Date Fri, 12 May 2006 15:41:08 GMT
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)

       --Will

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


Mime
View raw message