What can AOP do that OOP can’t do?

AOP is OO; Aspects are objects.

I don’t understand why the either/or mentality.

AOP is the perfect choice for chained, cross-cutting concerns (e.g. logging, security, transactions, remote proxying, etc.)


I think the criticisms offered by the OP are subjective and not as universally widespread as stated. Assertions stated without proof can be dismissed without proof.

I don’t believe in using magic, but AOP is not magic if you understand it. I understand it. Perhaps the OP does not. If that’s the case, and the OP is more comfortable with an OO solution, I’d say go for it.

“Seems to me to be unnecessary” is a mere opinion, offered without proof. There’s no answer to that except “I disagree.”

I think AOP is perfect for those cases because I can apply it in a declarative way. I can write an aspect class once and apply it in many places with fine-grained control, changing it in configuration rather than code. I can pick and choose which methods, classes, and packages have an aspect applied to them in configuration.

Try that with a hand-written OO approach.

Besides, AOP is object-oriented. You can look at it as a smart person giving you a domain-specific language or framework for what you want to do by hand. The common features have been abstracted out into something more general. Why would anyone object to that?

Leave a Comment