On Wed, 27 Mar 2002 07:11, Erik Hatcher wrote: > MatchingTask is abstract and would not be made final. �I got no problems > with abstract tasks! �:) > > We will not make any of the classes final that were in existence when Ant > 1.4.1 was released - it simply breaks backwards compatibility. > > There is nothing wrong with extending Task or MatchingTask - I am not > claiming that at all - they are designed to be extended. �Jar, however, is > not, at least not to the extent of adding features like you are doing. > Encapsulate - for the last time! �:) > > � � Erik
Erik, I just want to say that I fully support your line of argument on this matter. Subclassing existing Ant tasks, (and even creating/executing programmatically) seems to cause the biggest headaches wrt backwards compatibility. When functionality needs to be shared between tasks, it's much better to refactor that functionality out into a separate, well-defined helper class to be used by both Tasks. A few other notes that I agree with you on. (or I'm just sprouting off ;) ) * I tend to always favour delegation over inheritance * Where I use inheritance, I prefer to pull common functionality into a common, abstract superclass, so that concrete classes aren't themselves extended. (abstract or final, you choose...) * I tend to use interfaces everywhere that I need polymorphism. This approach leads to a greater number of simpler classes, and I believe produces more maintainable, more extensible code. I'm guessing that many people disagree with this approach (I'm often distressed by the lack of interfaces in the Java APIs themselves), but it works for me. I just wanted to let you know that you're well supported in this discussion and if I was in the same timezone, I might even be able to provide real-time support. -- ciao, Daz -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
