>>>>> "sr" == rubys <[EMAIL PROTECTED]> 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
become
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.
Notes:
* 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 /
replacement(?).
I even thought about something like
<task>
<match>
<include ... />
</match>
</task>
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.
Stefan
