Comment Re:Aspect-oriented? (Score 2, Insightful) 130
I have to say, I can tell you've never seen a good example of AOP in action. It's a very powerful tool for certain kinds of problems. Crosscutting concerns is not just a buzzword. There are certain requirments in many software projects that cut accross many modules and sections; examples being security, transactionality, policy enforcement, the list goes on and one. One example is any problem that could be solved with the Visitor pattern can be solved with aspects in way that is far simpler and maintainable.
I work on a very large software project that uses aspect in several different ways. On example is for transaction management. We have an aspect that is able to start a transaction at any method marked with a @Transactional annotation. And you can create aspects that do things like inject a caching system objects in a way that doesn't force the object to be aware that it is being cached. Catch business events that should happen at certain times without littering your code with calls to raising that event. It an extremly powerful tool.
The problems with aspects are the lack of tool support. It can slow down compiles and mess with debuggers at times (I know, I've had to deal with this). However this will improve over time. Another improvement is runtime weaving, where the aspects are woven into the code at runtime. This allow you to run the aspects when you actually need them (production, integration testing) and not when you don't (unit testing).
And the compaint about not knowing where the flow of control is going is similar to the complaints about OO and ploymorphism. Yes, it can make it a little harder understand a program at first, but with the proper tools and some time, it will make the program far more maintainable.
You have to know when and where to use it.
I work on a very large software project that uses aspect in several different ways. On example is for transaction management. We have an aspect that is able to start a transaction at any method marked with a @Transactional annotation. And you can create aspects that do things like inject a caching system objects in a way that doesn't force the object to be aware that it is being cached. Catch business events that should happen at certain times without littering your code with calls to raising that event. It an extremly powerful tool.
The problems with aspects are the lack of tool support. It can slow down compiles and mess with debuggers at times (I know, I've had to deal with this). However this will improve over time. Another improvement is runtime weaving, where the aspects are woven into the code at runtime. This allow you to run the aspects when you actually need them (production, integration testing) and not when you don't (unit testing).
And the compaint about not knowing where the flow of control is going is similar to the complaints about OO and ploymorphism. Yes, it can make it a little harder understand a program at first, but with the proper tools and some time, it will make the program far more maintainable.
You have to know when and where to use it.
