commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [IO] filefilter sub-package
Date Mon, 29 Jul 2002 08:36:39 GMT


On Mon, 29 Jul 2002, Ola Berg wrote:

> Hen writes:
>
> >On Ola Berg\'s suggestion I worked at an Abstract class which merges the
> >filename-filter and file-filter interfaces together.
>
> Cool. But you could have asked, and I could have done it. Anyway...

Sorry, I was bored and looking to play with something :)

>
> >The only fault with
> >the one Ola provided was that it only fit if all
> >subclasses wanted to be
> >FilenameFilters.
>
> Well, yes, but I didn\'t think of it as a fault, but as a way of
> enforcing it\'s role as an adapter superclass for FilenameFilter
> classes wanting to upgrade themselves to FileFilter classes. In order
> to prevent accidental misuse I made the accept( File dir, String
> fileName) method abstract, meaning that any concrete descendant _has_
> to define an implementation for the FilenameFilter interface.

It slams into the two classic examples of File-Filters though. The first
is that of a filename-extension filter. This works best on filenames as it
doesn't care about the actual File object, just its String name. The
second is directory filter. This works best on File objects as it wants to
know if that File object represents a directory. If it has to define a
FilenameFilter interface, it'll define it the same way every other natural
FileFilter interface will.

Probably this is unnecessary, but it feels poor to choose one
implementation other the other. Maybe there could be two abstract classes,
one for each type of sub-class, with a common interface between them.

>
> But before I say too much, I will check out your solution and see for
> myself.
>
> BTW, is there a need for doing his adaption dynamically too? My
> solution was proposed as a static way of doing it (simply add
> extends... in the source code).

If you mean the poorly named DelegateFileFilter, it's because three of the
filters currently there are CompositeFilters, linking file-filters
together. They have to have an interface to work upon -
Jakarta-FileFilter, however there also has to be a way of taking an
existing FileFilter/FilenameFilter from java.io and working upon that,
thus the DelegateFileFilter.

There's probably a more elegant solution?

Hen


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


Mime
View raw message