Stefan Bodewig a écrit :
On 2008-11-14, Nicolas Lalevée <[EMAIL PROTECTED]> wrote:
I am not sure of how are used the "Resource" in the Ant code, but it
makes me think of the Eclipse adapters (probably a design pattern ?):
http://www.jeffreyricker.com/papers/Eclipse-Adapters.pdf
Sounds reasonable.
Though it changes the tests of the appendability, the touchability,
etc... of a Resource in the ant code, the "instanceof+cast" would be
replaced by some "getAdapter". This solution is not very self-
contained...
Yes. I may stick a single subclass for FileProvider resources and
modify all occurances of Appendable and Touchable to use the adapter
method.
But I see another solution, quite different. Probably most of the work
should be done in the Resource class:
I thought about that, but Resource is already doing way too much IMHO.
Well, in fact here you want a functionality to Resource (AFAIU). And it
makes me think of the multi-inheritance issue. And after a long debate
with a colleague of mine, he convinced me that multi-inheritance can
always be resolved with single-inheritance + composition: extract the
functionality into its own class and make it a composition of the main
class. Even more, since I understood it, my code began very modular
actually, even if it began to be composed of a lot of handler.handle().
If you choose the former solution, then each time you want to add
another implementation of Resource with some new capability, you will
have to support it in MappedResource. By the way, what about the
Resource implementation in some ant plugins ? Is the Resource API
exported ? Wouldn't the former solution break some ant plugin ?
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
