Yeah. I agree valueOf would work just fine, but unless I'm missing
something, the current implementation doesn't have this. The purpose of
my comments was to say that I thought it should have something along
those lines.
I'm unsure of the value of having the static Factories, e.g.
ArchiverFactory.ZIP
--Will
Sandy McArthur wrote:
On 5/12/06, will pugh <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
