Posted by Dean Wampler Wed, 21 Mar 2007 16:30:22 GMT
I’ve started a series of blogs on AOSD at Object Mentor. The first is a blog on the the AOSD 2007 Conference, which was last week. I’m planning subsequent blogs on where I think AOSD needs to go next, AOSD in dynamic languages, and principles of good aspect-oriented design. Please join me there!
Posted by Dean Wampler Mon, 05 Mar 2007 00:57:00 GMT
I’m presenting a paper at AOSD 2007 called Aspect-Oriented Design Principles: Lessons from Object-Oriented Design (PDF on the AOSD 2007 Conference web site).
AOSD won’t succeed in the mainstream unless it can be used to build software with the essential characteristics expected of production code, e.g., agility, extensibility, maintainability, and of course, quality.
It shouldn’t be too surprising that principles of good OOSD apply to AOSD. Conversely, ignoring those principles is a recipe for failure. In fact, I argue that some of the early problems people have encountered with aspects and software “evolution” are really just cases of not applying these principles.
In this paper, I review 11 Principles of Good Object-Oriented Design, cataloged by Robert Martin, and discuss how they apply to aspect-oriented design (AOD), how aspects help implement them (e.g., by making it easier to achieve separation of concerns), how aspects introduce nuances into the interpretations of these principles, and finally, extensions of these principles unique to aspects.
My hope is that writers of aspects will be more successful if they apply these principles and that AOSD will prosper as a result.
I should warn you that the paper is written in a somewhat academic style, but hopefully the practicality of the principles will be clear. I’d love to hear your feedback! As time permits, I’ll try to blog about these principles here, in a less formal style ;)
By the way, if you’re really interested in AOSD, I hope to see you in Vancouver at the AOSD conference, March 12-16. I will be teaching a half-day tutorial on AOD. Please join me!
Posted by Dean Wampler Fri, 02 Mar 2007 16:03:00 GMT
A Contract4J5 user reported performance problems using Groovy. After some investigation, it appears that using the Bean Scripting Framework (BSF) increases the overhead of script evaluation by a factor of 3 or so! The overhead for script evaluation is already very high (roughly a factor of 7-10 times slower compared to no contracts). Scripting is expensive if used heavily, as it is in C4J!!
I’m not sure why BSF’s overhead is so high, but I’m going to implement support for Groovy and JRuby that bypasses BSF. This may take a while to complete, as I have a busy few weeks ahead.
The older non-BSF integration with Jexl is still in the distribution (although it’s currently marked as deprecated). If you want to use it, put the following code in your main or similar initialization methods:
Contract4J c4j = Contract4J.getInstance();
ContractEnforcer ce = c4j.getContractEnforcer();
ce.setExpressionInterpreter (new JexlExpressionInterpreter());Correction: You can also use the properties file configurator or the Spring configuration file options to specify Jexl without the BSF wrapper.
You’ll get warnings that JexlExpressionInterpreter is deprecated. You can safely ignore them. I’ll remove that javadoc tag in the next minor update.
Longer term, I’m trying to improve the use of caching to further reduce the overhead of C4J.
