Today is the first day since the May Day holiday, and there are four days left before the next week. This week is mainly about re-learning Spring. In these four days, I will analyze and understand from the following perspectives.

(1) AOP understanding and analysis

(2) IOC understanding and analysis

(3) Understanding and analysis of beans

(4) Understanding and analysis of Spring configuration files

First of all, today’s understanding and analysis of AOP, the understanding of AOP is also elaborated separately, thinking about a technology, basically from the school when the textbook elaborated a new knowledge of the order. First: What is AOP?

Second: Why AOP? Or what problem does AOP solve?

Third: How to implement AOP easily?

Fourth: What does AOP help us think about when we write code?

Now, to get started on AOP,

What is AOP?

1.1 Concept Introduction

Spring’s mission is to simplify Java code development, and AOP, as a submodule of Spring, is no exception.

AOP is the abbreviation of Aspect Oriented Programming (Aspect Oriented Programming), and OOP (object Oriented Programming) is a kind of Programming thought, is a supplement to OOP.

How do you understand what AOP is? Take logging as an example. In many management systems, such as order system, push system and so on, logging is required. If there is logging code in every business logic, there is too much duplication.

Simply log the relevant logic code, unified encapsulation. Then embed it where needed. AOP is all about embedding. Look at the graph below.


Add order Edit order cancel order push order log transaction

AOP aims to separate crosscutting concerns from business principal logic to improve modularity of programs (and business modules focus only on business logic rather than general logic such as logging, security, and transactions)

Some of the terms mentioned above, such as section, focus, crosscutting, etc., are explained below.

1.2 Explanation of Nouns

  1. AOP has its own set of terms, which we must understand in order to better understand AOP. In order to make it easier for you to understand, I will use the class representative assignment as an example.

    1. Notice (Advice)

      Defines what needs to be done before and after receiving an assignment. Common notification types include: before, After, after-RETURNING, and around.

    2. The join (JoinPoint)

      A join point is a point at runtime at which the program is allowed to insert facets. It can be a function, a package path, a class, or an exception thrown. It’s kind of like when you can pick up your work.

    3. PointCut

      Pointcuts are used to define the location of the cut, that is, which join point calls are captured and then the “notification” operation is performed (where).

    4. Aspect

      A facet is an aggregation of pointcuts and notifications, defining which pointcuts do what notifications.

    5. Target Object

      An object woven into a section.

    6. Introduction

      Imports allow us to add new methods or attributes to existing classes.

    7. Weaving

      Weaving is the process of applying a cut surface to the corresponding join point of the cut point. The section is woven into the target object at the specified join point.

The specific relationship is graphically expressed as follows:


2. Why AOP?

Here are the definitions, and the reason for introducing AOP is certainly to address some of the pain points in current development:

(1) In the current development, each other are modular development, using AOP can effectively achieve modular ideas.

(2) The auxiliary logic (log, security, monitoring, etc.) is stripped from the business principal logic and synchronously developed.

AOP is the idea of stripping away some business logic and then combining it with the main business logic to achieve the desired functional logic.

How to implement AOP easily?

3.1 AOP programming ideas

This diagram is a simple idea.


Specify requirements create aspect class definitions pointcut definitions inform thinking: what to do in which method and when (before method? Methods after? Around?) That is, which join point is selected to execute the notification near the pointcut (before? after?) What to do

Let’s define a simple logging example to implement AOP. The original annotation is used:

3.2 Case implementation of AOP

3.2.1 Clear Requirements

Adding @fddlog to a method automatically prints information before and after the method is executed. Here’s an example of putting an elephant in a fridge:

3.2.2 Basic interface and implementation

public interface ElephentToRe{

  public void toRe(a);

}

Copy the code

The implementation class is as follows:

public class ElephentToReImpl implements ElephentToRe{

  public void toRe(a) {

    System.out.println("Put the elephant in the fridge.");

  }

}

Copy the code

3.2.3 Define facets and notifications

public class ElephentToReHelper{

    public void beforeElephentToRe(a){

        System.out.println("Open the fridge door.");

    }

    public void afterElephentToRe(a){

        System.out.println("Close the fridge door.");

    }

}

Copy the code

Configuration is good

<? xml version="1.0" encoding="UTF-8"? >

<beans xmlns="http://www.springframework.org/schema/beans"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"

  xsi:schemaLocation="http://www.springframework.org/schema/beans

  http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

  http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">

<! Define the notification content, that is, what needs to be done before and after the pointcut executes.

  <bean id="elephentToReHelper" class="com.fdd.bean.ElephentToReHelper"></bean>

<! -- Define proxy -->

  <bean id="elephentToReImpl" class="com.fdd.bean.ElephentToReImpl"></bean>

  <aop:config>

    <aop:aspect ref="elephentToReHelper">

      <aop:before method="beforeElephentToRe" pointcut="execution(* *.toRe(..) )" />

      <aop:after method="afterElephentToRe" pointcut="execution(* *.toRe(..) )" />

    </aop:aspect>

  </aop:config>

</beans>

Copy the code

3.2.4 Test to see the effect

public class Test {

  public static void main(String[] args){

    @SuppressWarnings("resource")

    ApplicationContext appCtx = new FileSystemXmlApplicationContext("application.xml");

    ElephentToRe elephentToReImpl = (ElephentToRe)appCtx.getBean("elephentToReImpl");

    elephentToReImpl.toRe();

  }

}

Copy the code

The above approach is done through pure POJO facets. The implementation is also relatively simple.

My view on AOP thinking

Any new technology is designed to address some of the pain points in current development. For AOP, it mainly abstracts some functional code and encapsulates it with the main business logic code. Weave in as needed.

The way I see it

(1) When developing code at ordinary times, some common and commonly used functional codes can be encapsulated, and dynamic configuration can be achieved as far as possible. Different functional modules only need to be woven in.

(2) Define the template of business logic, for example, if you want to solve a certain business function, if the page is similar, you can combine it according to the basic framework, and then use the configuration platform for controllable configuration.