AOP与OOP

OOP introduced object abstraction, and now AOP introduces concern abstraction. Currently, OOP is the methodology of
choice for most new software development projects. OOP’s strength lies in modeling common behavior. However, as we will see shortly and as you may have already experienced, it does not do as good a job in addressing behaviors that
span many, often unrelated, modules. AOP fills this void.

AOP is not an antidote for bad or insufficient design. In fact, it is very tough to implement crosscutting concerns in
a poorly designed core system. You will still need to create a solid core architecture using traditional design methodologies, such as OOP. What AOP offers is not a completely new design process, but an additional means that allows the architect to address future potential requirements without breaking the core system architecture, and to spend less time on crosscutting concerns during the initial design phase, since they can be woven into the system as they are required without compromising the original design.