Stuff like the fork-join framework is, i.e. search filters, aggregate operations, etc, expressed as arbitrary closures and then re-used en masse in a framework against various data structures. This is really a classic example where the class and method name that an interface force are quite unnecessary and having to introduce such types throughout the framework is onerous.
Well, isn't that kind of contradicting, defining something like a Filter, which can be reused throughout without defining a type? Can you elaborate on that? I've always had this notion, that closures wouldn't necessarily increase code reuse, maybe you can help me out here.
with kind regards, David Linsin - - - - - - - - - - - - - - - - - - - - - - - - email: [EMAIL PROTECTED] blog: http://dlinsin.blogspot.com On Oct 24, 2008, at 1:26 PM, Jess Holle wrote:
Rick wrote:I think the best way to reuse code in Java is the simplest. Which is to say: subclassing. Unfortunately, the current fashion is that more classes = worse*, which leads to the library style of subclassing, with the attendantproblems that people have mentioned (e.g. who maintains it) as well asother problems such as trying to be all things to all people.That leads to overly complex code, because your base classes (i.e. thelibrary) have to accommodate every way in which users of the librarymight want to use the library in the future. Good luck with that one.Typically when someone wants to re-use code, they have some existing code that already does 90% of what they want, and they then have to try to figure a way to shoe-horn the remaining behaviour out of or into the base class (which of course will mess up everyone else that relies on those classes...). Instead, they should simply subclass the class with 90% of the behaviour they want, and then either add on, or override the methods where they want the behaviour to be slightly different. *We wouldn't even be having the closure debate for instance if people would just man up and create a new class, or, in the case of the closure 'killer app' - which is UI - instead of creating anonymous inner classes they should be subclassing Action.I don't see UI as the "killer app" for closures.Stuff like the fork-join framework is, i.e. search filters, aggregate operations, etc, expressed as arbitrary closures and then re-used en masse in a framework against various data structures. This is really a classic example where the class and method name that an interface force are quite unnecessary and having to introduce such types throughout the framework is onerous. In most cases, including in UI in my book, having a class and method name and associated Javadoc are good things for those trying to learn and understand and which an API author shouldn't skip out of laziness. In areas like fork-join, the balance shifts towards closures.As for subclassing vs. composition/collaboration of classes, this is at this point an old debate with the pendulum having swung too far both ways at times. In reality the API designer has to make good choices about what is best expressed in each fashion for optimal maintenance and re-use. In almost all cases the designer gets this wrong at least in part, but hopefully isn't so far off that the API is onerous to extend/re-use in most cases -- or to use at all (which can be the case if one goes too far down the road of splitting every possible aspect/responsibility into a separate class and then makes the API user figure out how to put them all together).-- Jess Holle --~--~---------~--~----~------------~-------~--~----~You received this message because you are subscribed to the Google Groups "The Java Posse" group.To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
