Chapter 1. Discovering AOP

 

This chapter covers

  • Understanding crosscutting concerns
  • Modularizing crosscutting concerns using AOP
  • Understanding AOP languages

Reflect back on your last project, and compare it with a project you worked on a few years back. What’s the difference? One word: complexity. Today’s software systems are complex, and all indications point to even faster growth in software complexity in the coming years. What can a software developer do to manage complexity?

If complexity is the problem, modularization is the solution. By breaking the problem into more manageable pieces, you have a better shot at implementing each piece. When you’re faced with complex software requirements, you’re likely to break those into multiple parts such as business functionality, data access, and presentation logic. We call each of these functionalities concerns of the system. In a banking system, you may be concerned with customer management, account management, and loan management. You may also have an implementation of data access and the web layer. We call these core concerns because they form the core functionality of the system. Other concerns, such as security, logging, resource pooling, caching, performance monitoring, concurrency control, and transaction management, cut across—or crosscut—many other modules. We call these functionalities crosscutting concerns.

1.1. Life without AOP

1.2. Modularizing with AOP

1.3. Anatomy of an AOP language

1.4. Fundamental concepts in AOP

1.5. AOP by analogy

1.6. Implementations of AOP

1.7. Alternatives to AOP

1.8. Costs and benefits of AOP

1.9. Summary

sitemap