Before you start reading this chapter, I want to share something with you; as I was writing this chapter, my wife Anamika, was taking a selfie and uploading it to several social media sites such as Facebook and WhatsApp. She keeps a track of the likes, However, uploading more photos uses more mobile data, and mobile data costs money. I rarely use social media as I prefer to avoid paying more to the internet company. Every month, the internet company knows how much to bill us. Now consider what would happen if the internet usage, total call duration and bill calculation was meticulously planned and managed by us? It's possible that some obsessive internet users would manage it and I'm really clueless as to how.

Calculating billing for internet usage and calls is an important function, but it is still not predominant for most internet users. For those like my wife, taking selfies, uploading photos to social media, and watching videos on YouTube are the kinds of things that most internet users are actively involved in. Managing and calculating their internet bill is a passive action for internet users.

Similarly some modules of the enterprise applications are like the internet billing calculator for our internet usage. There are some modules in the application that have important functionalities that need to be placed at multiple points in the application. But it is unexpected to explicitly call these functionalities at every points. Functionalities such as logging, security, and transaction management are important for your application but your business objects are not actively participating in it because your business objects need to focus on the business domain problems they're designed for, and leave certain aspects to be handled by someone else.

In software development, there are specific tasks to be performed at certain points in an application. These tasks or functions are known as cross-cutting concerns. In an application, all cross-cutting concerns are separate from the business logic of this application. Spring provides a module Aspect-Oriented Programming (AOP) to separate these cross-cutting concerns from the business logic.

As in Chapter 4, Wiring Beans using Dependency Injection Pattern, you learned about the dependency injection to configure and resolve dependencies of collaborating objects in the application. Whereas DI promotes programming to interface and decoupling application objects from each other, Spring AOP promotes decoupling between the application's business logic and the cross-cutting concerns in the application.

In our bankapp example, transferring money from one account to another account is a business logic but logging this activity and securing the transaction are cross-cutting concerns in our bankapp application. That means logging, security, and transaction are common examples of the application of aspects.

In this chapter, you will explore Spring's support for aspects. It will cover the following points:

• Proxy pattern in Spring
• Adapter design pattern to handle load time weaving
• Decorator design pattern
• Aspect-oriented programming
• Problems resolved by AOP
• Core AOP concepts
• Defining point cuts
• Implementing Advices
• Creating aspects
• Understanding AOP proxies

Before we go further into our Spring AOP discussion, let's first understand the implemented patterns under the Spring AOP Framework, and see how these patterns are applied.