ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Possible Exec and MatchingTask Refactorings
Date Wed, 28 Jun 2000 10:28:18 GMT
>>>>> "sr" == rubys  <> writes:

 sr> The design pattern could be as simple as matching all public
 sr> fields, or could be based on the names of the fields having a
 sr> well defined prefix, or be based on the class itself being
 sr> enabled as a delegate.

I'd go for a method with a given prefix like ProjectHelper is allready
using for attributes and nested elements. 

My proposal for the general case:

ProjectHelper scans the Task at hand for methods whose name starts
with "getDelegate", that take no arguments and return an Object type -
primitive are not interesting.

For each such method retrieve attribute setters and nested element
creators and add them to the list of possible setter methods for the
task - not going into implemntation details here.

Lets keep MatchingTaskImpl as described in my first article - but
forget the interface - then MatchingTask like it is now would simply

public abstract class MatchingTask extends Task {

    private MatchingTaskImpl matchingBehavior = new MatchingTaskImpl();

    public MatchingTaskImpl getDelegateMatchingBehavior() {
        return matchingBehavior;

    protected DirectoryScanner getDirectoryScanner(File baseDir) {
        return matchingBehavior.getDirectoryScanner(baseDir);

Every task that wants MatchingTask funcionality could do the same -
without any need for getDirectoryScanner of course.


* In the same course I'd like to modify ProjectHandler to do the whole
reflection part once and only once per class. I think the added
overhead of my proposal isn't that high.

* I'm not married to the "getDelegate" prefix, what I really want to
express is that there should be only one per delegated functionality.

* The pattern is quite similar to the pattern employed for nested
elements. Currently createXXX is used as a prefix and IIRC there has
been agreement to use void addXXX(ObjectType) as an alternative /

I even thought about something like

    <include ... />

but that would mean (1) rewriting a lot of buildfiles - which is not
my major concern - and (2) you could have an arbitrary number of match
attributes nested into a task - I wouldn't know what they would mean.


View raw message