Things that are done in OOP can be done in procedural, although there is more coding involved. The same is true with AOP, things can be done using standard OOP patterns such as Template Method, but its less code to maintain in AOP. Also AOP is not mutually exclusive to OOP, some things are easier to deal with in an OOP fashion than AOP fashion. The same is true with OOP and procedural, which is why we have the
statickeyword in Java for some things that can be better written in a procedural form.
Surfing on the net I see how some people find that AOP is bad idea. I think AOP has the capability of being both good and bad at the same time, just like OOP. Both have the feature that things do not go in a straight line. This is much more so with AOP, so people can easily get lost.
There were two solutions found for this in OOP. One is called Design Patterns which help people think and describe in a more higher level than just the code. The other is called Refactoring which help people think and describe how to fix badly written code.
AOP just needs those two solutions put in its place to rid us of unreadable AOP code.
Samples of AOP refactorings I can think of:
- Replace wrapper with pointcut.
- You find that a piece of code is repeated over and over again in the beginning or the end of a code block. Rather than putting in all the code necessary you have two options, create a template method so you don't have to repeat the same code or you can introduce a point cut. Introducing a pointcut has one advantage being the class being developed can be a POJO with no fragile superclass.
- Replace template method with pointcuts.
- You can replace template methods with pointcuts to make your classes more POJO
- Replace reflection with aspect.
- You can replace complex reflection code with aspects. This would allow for more type safe code and elimination of possibly duplicated reflection code or APIs.
Samples of AOP patterns I can think of:
- Method Wrapper
- Wraps a method with some code at the start and the end.