preface

I believe that every reader knows how to use Spring in his work and study. For a junior development engineer, it should be enough to only know how to use Spring and be able to complete tasks quickly through Spring. However, if you want to move forward to a higher level, it is essential to systematically learn and master its underlying principles.

When everyone is interviewing, Spring should be an unavoidable barrier and can be used skillfully. It's not difficult to know that its underlying principle is one step higher than others. This article will briefly talk about some knowledge of Spring, hoping to help you on the way to the interview. Spring is an open source framework. Its original intention is to solve the complexity of enterprise application development. Spring is not limited to server-side development. Any java application can become simpler, testable and loosely coupled with the help of spring. In order to reduce the complexity of Java development, Spring adopts the following four key strategies:

• Lightweight and minimally invasive programming based on POJO;
• Loose coupling is realized through dependency injection and interface oriented;
• Declarative programming based on facets and conventions;
• Reduce boilerplate code through facets and templates.

Almost everything Spring does is implemented around the above four strategies, and its core is to simplify java development.

Lightweight POJO

In the daily development process, most people may feel that many frameworks force applications to inherit their classes or implement their interfaces, which will lead to the binding of programs and frameworks. Speaking of this, the framework we use now is like this. All modules, including DAO and Service, will forcibly inherit the classes in the framework, Application and framework binding are dead. Spring tries its best to avoid confusing your application code because of its API. Spring will not force you to implement its interface or inherit its classes. The most serious thing is that a Lei will use spring annotations. Spring's non intrusive programming means that this class plays the same role in spring applications and non spring applications.

Dependency injection

Any meaningful application must be composed of multiple classes. Without Spring, each object is responsible for managing the references of objects cooperating with itself, which will lead to highly coupled and difficult to test code.

public class Train implements Transport{
   private Water water;
   public Train() {
       water = new Water();
  }
   public void catchGoods(){
       water.waterSomthing();
  }
}

You can see the above code. Train creates a Water object in its constructor, which creates a tight coupling between the two objects. The train can transport Water to irrigate farmland, but it may not be in line if it is used to transport coal for heating. During unit testing, we should ensure that waterSomthing can also be executed when the catchGoods method is executed. If we do so, we will not be able to execute unit testing. Coupling has two sides. On the one hand, the tightly coupled code is difficult to test, take and understand. If one place is modified, it may cause other bugs (remember that when I first went to the company, I talked about development specifications. One interface should try to do only one thing, and one interface should not provide services for multiple places at the same time), On the other hand, code without coupling can do nothing at all. With Spring, the dependency of objects is completed by the third-party component responsible for coordinating each object. Objects do not need to be created by themselves. Dependency injection will automatically hand over the dependency to the target object instead of letting the object get it by itself.

public class Train implements Transport{
   private Water water;
   public Train(Water water) {
       this.water = water;
  }
   public void catchGoods(){
       water.waterSomthing();
  }
}

After our changes, Train will no longer create it by itself, but pass it in as a constructor parameter, which is also a way of dependency injection: constructor injection. This enables loose coupling. The behavior of creating collaboration between application components is usually called assembly. Spring has a variety of ways to assemble bean s, and XML is a common way.

<?xml version="1.0" encoding="UTF-8"?>
<!--DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd" -->
<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
   <bean id="train" class="com.kr.caption.spring.Train">
       <constructor-arg ref="water"/>
   </bean>
   <bean id="water" class="com.kr.caption.spring.Water"/>
</beans>

In the above xml file, the two objects are declared as bean s in Spring. In Train, a reference to Water is passed in during construction as constructor parameters.

@Configuration
public class TrainConfig {
   @Bean
   public Transport train(){
       return new Train(water());
  }
   @Bean
   public Water water(){
       return new Water();
  }
}

The above is a java based configuration. Both configurations have the same effect. Spring loads bean definitions and assembles them through the application context. Spring application context is fully responsible for the creation and assembly of objects. Spring has a variety of context implementations. The main difference between them is only how to load configuration.

public class application {
   public static void main(String[] args) {
       ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:application_example.xml");
       Train bean = context.getBean(Train.class);
       bean.catchGoods();
  }
}

The main method here is based on application_example.xml creates a Spring application context, and then you can get an instance object and call the method directly.

Aspect oriented programming

The system is composed of different components, which not only realize their own core functions, but also undertake some other responsibilities. Such as logging, transaction management and security, which usually run through various components of the whole project. If you don't deal with this part systematically, your code will contain a lot of duplicate code. If you Abstract these individual modules into a module, other modules only call its methods, and the method calls will still appear in each module. AOP will modularize these services and apply them declaratively to the modules they need to affect, so that other modules will only focus on their own business and do not need to understand the relevant logic and code of these services.