Slashdot Mirror
Aspect-Oriented Programming Article On JavaWorld
Some Guy writes: "Javaworld has another article (the second in a series of three) on Aspect-Oriented Programming. Grady Booch wrote last year that AOP is one of three signs of a disruptive software technology in the horizon: a technology that could take us to the next level beyond object-oriented programming."
I think you are missing what the paradigm suggessted in AOP is; it is a concept that is recognized in the OOP community as "Separation of Concerns." You can do separatin of concerns today if you can agree on a framework and are quite explicit about it. It is much like Object Orientecd Programming and late binding/polymorphism, you could do all of those things in the previous generation of languages without language syntax. Heck OOP is even done today in the GTK widget set.
The difference is that when the concepts are supported in the languaes it is (a) orders of magnatude easier for the developer proficient in those skills to do it and (b) it allows for an order of magnitude more developers to grasp the concept and exploit it.
Java's EJBs are a current example of doing separation of concerns (SOC) without language bindings, in fact it it explicit in the original specification. The business rule writer doesn't need to know how the deployer deploys the EJBs and they don't need to know if it is an Oracle Database or DB2 or an IPlanet directory server serving as the persistance for the objects. As long as they follow an establised set of rules, such as business rules don't create thread objects and the deployer respects and stores all of the data that it is told to store it works. Then the person writing the business rules doesn't need to know about load balanceing and clusering and the deployer deploying into the load-balanced and clustered environment doesn't need to know a rats ass about the business rules or any other parts of the workflow for that EJB. Thus the people who do procurement rules procure and the people who know scaleability scale. In fact, the only time that the business rule guy and the deployment guy would need to talk is at the company christmas party, and they don't even need to know who they are.
Now we can look at how SOC is done in EJB and that is generally the same style OOP was done in C (not C++). There was a lot of infrastructure and practice that had to be followed that was not enforced or explcit, and the means of doing them were often different from project to project and even module to module within a project. When C++ came along it was much easier to establish how you denote inheretance for polymorphism and when a functon should be virtual and thus bound late. AOP languages like AspectJ are providing the means to provide for these "aspects" (I don't like the name either) much as C++ did for the OOP practicces. Making it more accessable and maintainable.
I must a gree with Booch, AOP will be affecting the future of software development as dramatically as the OOP concepts did. And if one doesn't keep up come 2010 you will be maintaining old payroll programs on a low paying contract rather than leading or managing a team on new software development in AOP.
--Shemnon
Sure,
You have your regular OO program. Only you don't do the usual thing of littering with duplicate functionality for e.g. synchronization, persistance, security. This kind of code is what makes your program complex and generally requires rigid design rules in order not to blow up in your face. What AOP does instead is separate this kind functionality from your OO program into what is called an aspect.
Aspects consist of code and a pattern defining where this code is to be inserted in the OO program. This process is referred to as weaving.
Take for example logging. All large projects need this. Imagine you could just write down: for all public set methods in package X Y and Z: prior to execution write the name of the method that is called to the log. In aspectJ you'd define this functionality in a few lines of code whereas in your average OO language you would need to edit each and every public set method. In addition if you'd add a new public set method somewhere you would need to add the functionality manually. You might forget, introduce bugs (well, maybe not in logging).
Now logging is just the most simple example of an aspect. There are many more and the people at aspectj.org do a much job of explaining it than I can. So, go have a look with an open mind. Download the compiler, try the examples and use your imagination.
Jilles
Yeah, where are all my mod points when I need them?
I call these things Hype-Oriented Programming.
OOP, AOP, Design Patterns, CASE tools, eXtreme Programming, yadda, yadda, yadda. The problem is they are usually valuable and make significant contributions to the body of knowledge in CS and software engineering, but even the successful ones (OOP) never live up to the hype.
The solution is to stay informed and keep up with new ideas and techniques, but point your fingers and laugh at people who jump from trend to trend, often never getting around to producing anything!
(The worse is eXtreme Programming, but don't get me started; don't even get me started.)