I have worked on few projects in which both AOP and Object oriented paradigm were used. But, AOP usage was limited to logging only. I think AOP is a much more powerful technique. My question, to those who have worked with both AOP and OOP paradigm in projects, is, how do they come up with a solution, combining these powerful paradigms. Do they think AOPwise first and then design objects or vice versa. My general question to those who have used AOP extensively is, whether they find it a powerful modularizing technique. If yes, please quote examples.
-
AOP isn't composable - i.e. you can't combine arbitrary aspects and expect things to work. As a trivial example, if I add an aspect that increments an counter and you add one that decrements the same counter, the aspects are conflicting with each other. This is why AOP is limited to things like logging which don't have observable effects on the rest of the code.– DovalJul 27, 2014 at 20:48
Add a comment
|
3 Answers
In my experience, OOP and AOP are not mutually exclusive. AOP relates to encapsulating separate concerns as subsystems and exposing each through a fascade pattern to other concerns or the application domain itself. OOP is the technique most often used to write them modules (although there are functional styles in OOP languages which I have reiterated here: Is objected oriented programming paradigm outdated since it is anti-modular and anti-parallel?).
As for logging or other shared resources, it usually as a singleton and made accessible to many of these concerns.
I think of OOP as the concept allowing me to model the business, while AOP provides me with the possibility to model the technical infrastructure (logging, transactions, security) required to focus on the business logic in my OOP code. I can't give you proof why this would work best, but I think it is a reasonable heuristic to get a solution that you will still understand a few years after the start.
Some things are better expressed as OOP and others are better as AOP, and they can work rather nicely together. (Beware of anyone trying to tell you that one thing is universally better than another; life's hardly ever that clear cut. Let them provide evidence of their claim, and then evaluate whether it makes sense for you yourself.)
OOP works particularly well where you have functionality that is expressed as “apply an operation to this parcel of state” especially when the caller isn't required to know too much about the details of what is going on inside the operation. For example, telling a Dog to wag tail.
AOP works better when you have functionality that is wrapped around some other operation. Transactions are the classic example of this; it's much easier to get them right when you can tie them to the natural lifespan of some other piece of code like a method call. Logging and performance monitoring also work well.
I use both together in my applications. I claim that the combination is highly useful (and Spring is a reasonable way of doing the management of all the objects in the combined app). The overall design is definitely OOP first though; with AOP you hang it off some other framework that provides the mainline business logic.
