Return to Contents
1. Why AOP?
Consider a typical e-commerce project. This kind a project may contain lots of parts besides the core implementing, such as logging, caching, security, and so on. When doing OOP, these parts are directly inserted into the core implementing. For example, a typical method implementing may start with some logging, security checking for parameters, then check for caching, and then the main processing after all processing, maybe there will be some logging again.
What problems will come to a project of this kind? First, logging, caching and security codes are in every method. Although we can extract these kinds of codes to separately libraries or at least separately classes and methods, but still there will be similar codes for calling them in every method. But these kinds of codes may not directly relate to the business logics, so there are bad smells. Second, in a typical development life cycle, we may focus on the core business logics first, and after the core implementing is ok, we do debugging and add logging, caching or security codes iteratively. Oh, of course, in this way, each time we must manually add these kinds of codes to every method. Each time! Every method! How crazy a thing!
Can we prevent these bad smells? Can we separate codes to independent modules, core implementing and other related logging, caching, security like modules, develop, debug them independently, and merge them when necessary easily with little extra effort? We Can! Let’s AOP!