Original: www.aqcoder.com/post/45

Spring has two major features: Inversion of Control (IoC) and Aspect Oriented Programming (AOP).

A common way to achieve inversion of control is Dependency Injection (DI).

So why is IoC needed, and what is its essential purpose?

Decoupling. Everything is about decoupling

Simple implementation of IoC & DI

Let’s first look at a simple implementation of IoC to better understand the concept.

Suppose company A designs A Car class, but company A is only responsible for assembling cars, but not for the production of wheels, engines and other specific accessories. Company A cooperates with A number of companies that produce accessories at the same time. First, company B and C only produce wheels. In order to use the wheels produced by company B and COMPANY C at the same time, Company A specifies the interface rules of wheels:

public class IWheel { Size getSize(); Int getLevel(); Boolean run(); // Drive the wheel to roll}Copy the code

With the interface definition, both COMPANY B and company C follow this excuse to produce wheels, and company A can use them.

In the absence of A container like Spring, company A uses the following:

Public class Car {// Every manufacturer implements the wheel according to the standard interface, save the interface here, regardless of the implementation details. private IWheel wheel; Public void SetWheel(IWheel) {this.wheel = wheel; } public void run() {this.wheel.run(); }}Copy the code

The above code looks perfect, to achieve the purpose of decoupling, but also achieve the purpose of encapsulation, car manufacturers do not need wheel manufacturers how to drive the wheel, just call their own issued standard interface IWheel run method.

But the car needs to be instantiated, so the following code is coupled again:

Assume that the car produced by the automobile factory uses the wheels provided by manufacturer B, and the wheel class realized by manufacturer B is

public class BWheel implements IWheel { private String param; @Override public Size getSize() { return new Size(10, 10); } @Override public int getLevel() { return 10; } @Override public boolean run() { System.out.println("wheel run."); return true; } // B manufacturer's wheels are more advanced and need various parameters to run. public void setParam(String param) { this.param = param; }}Copy the code

Car manufacturer instantiates a car:

public class Application { public static void main(String[] args) { Car car = new Car(); // This is where the coupling occurs, because vendor B's code intrudes into vendor A's code. Wheel wheel = new BWheel(); // This parameter is unique to B. where.setParam("param only for B provider.") car.setWheel(wheel); car.run(); }}Copy the code

From the above we can see that the code of manufacturer B intruded into the code of manufacturer A. If the car manufacturer wants to use the wheel of manufacturer B, it needs to import the JAR package of manufacturer AND then sample their class. Given that there are so many parts in a car, and so many manufacturers for each part, the code of the car manufacturer will become more and more bloated and difficult to maintain. It’s a hell to get back there.

To make matters worse, the manufacturer of each wheel (accessory) may have its own set of parameters, which can clutter up the car manufacturer’s code.

So what happens with frameworks like Spring?

@service public class Car {// Use the Spring framework to inject the wheels. Note that there is no specific manufacturer's wheels specified here. // No vendor specific parameters are set. @Autowired private IWheel wheel; public void run() { wheel.run(); }}Copy the code

So how to define which manufacturer’s wheel is specifically used? In the Spring framework’s XML configuration:

<bean id="wheel" class="com.b.BWheel">
    <property name="param" value="param only for B provider." />
</bean>Copy the code

At this point, it turns out that the Spring framework helped us hardcode the intrusions and transform the XML configuration. When replacing the wheels of manufacturer C, you simply replace the XML configuration file.

This may seem perfect, but if you look carefully you will see that this only turns the coupling part into configuration and, as the system gets bigger and bigger, the configuration file gets bigger and bigger and more complex and harder to maintain.

Sure, this may not seem like A complete decoupling, since the configuration file is still maintained by the car manufacturer (A), but there is an essential difference in separating this part of the configuration: there is no code intrusion.

The car manufacturer’s Java code does not contain the wheel manufacturer B’s code, and all the configuration is pulled out into an XML file.

With fewer and more features from wheel vendors, XML configuration files became more complex, hence SpringBoot.

SpringBoot’s various starter plug-ins bear the work of configuration files, after all, their own production of components, what configuration is the most clear. So the whole engineering structure becomes this.

To our surprise at this point, with the Spring framework, we are completely decoupled. Automakers only need to release standard interfaces for each component and reference the component manufacturer’s starter engineering package to complete the assembly.

Mapping to the code we normally use looks like this:

Auto manufacturers –> our engineered wheel manufacturers –> Druid, MyBatis, etc

In the boot project, as long as we introduce the relevant boot-starter dependency, the SpringBoot framework will automatically complete the assembly work, need to configure some parameters when using some annotations or inherited configuration class, you can achieve the configuration.

conclusion

The essence of IOC is decoupling. The greatest thing about the whole Spring framework is decoupling. Decoupling is very important to the architecture design of large-scale software engineering. Decoupling can make the software architecture clear, enable each component producer to focus on their own internal implementation logic, and enable each component to be easily assembled and matched flexibly.

This article is published by OpenWrite, a blogging tool platform