When I was edited in "programmer", I have hosted a technical topic about AOP. With the legendary "keen technical smell" (huh, it sounds like a dog nose), I feel that AOP will be a very useful thing, although I don't know what to use. (Laser nonsense: "Programmer" is recruiting technical editing, if you think that you will blow your own bragging, it is good at creative - just like me, I will suggest you try this position.)
My friend's demon has repeatedly speaking "GP and 'Event Programming'" this topic. According to my understanding, the so-called "event programming" is mainly solved by an orthogonal decomposition problem, and GP happens to provide a paradigm that provides orthogonal decomposition. Recently, the foreign J2EE community often discusses AOP, and it seems that they believe that the orthogonal decomposition capacity provided by AOP is very suitable for solving problems often encountered by EAI, such as business flow ... I started to blow back. Let's put down the ghost, I want to see what AOP can do.
AOP can be used for the use restriction of the Java program. Before released, use aspectj to give each class into each class into authentication logic, so that it is difficult to crack. About how AOP is used for authentication and authorization, there is an article here: http://www.theserverside.com/resources/review/aspectJ/chapter10_ASpectj.zip
Another fascinating result is Jan Hannemann and Gregor Kiczales, they use AOP to implement 23 design patterns of GOF. For 17 modes, they successfully removed code-based dependencies between participants with AspectJ. It is generally believed that design patterns also makes code complicated and difficult to read, and "Get Fractal" mode frame code is confused with the "completion function" service code, which is easy to lose the reader. Therefore, this experiment conducted by Jan Hannemann and Gregor Kiczales is quite meaningful, which may greatly improve the enthusiasm of ordinary programmers using design patterns. It can even be expected that the design pattern is implemented by a higher level of programmers, and it is only necessary to woven it into the module required.
In http://www.cs.ubc.ca/~jan/aodps/gof.zip can download the code example of the AOP implementation GOF mode. Before compiling these examples, you need to install JDK and AspectJ (http://www.aspectj.org) first. They made a speech entitled "Design Pattern Implementination in Java and Aspectj" at http://www.cs/oopsla2002/oopsla02-patterns.pdf at http://www.cs/oopsla2002/oopsla02-patterns.pdf See the full text of this speech.
Joshua Kerievsky has written a series of articles called "Refactoring to Patterns". He believes that the pre-introduction mode is likely to lead to over-engineering. Perhaps, the future mode community can consider the idea of "refactoring to aspects": extract the design mode into an aspect and woven it into the required modules. Flexibility and code clear, fish and bear palms can be affected?
Jan Hannemann and Gregor Kiczales Homepage: http://www.cs.ubc.ca/~jan/aodps/
Information on AOP and AspectJ: http://www.aspectj.org
"Programmer" Introduction to AOP: http://www.cbs.net/magazine/old/200211.shtm
