This article has been included in my 79K Star’s Java open source project JavaGuide: github.com/Snailclimb/… (The “Java Learning + Interview Guide” covers the core knowledge most Java programmers need to master.)

Related Reading: End scatter flowers! Github’s Java interview guide approaches 80K likes!

This article is submitted for readers!

This article will expand the explanation of IoC & AOP from the following issues

  • What is IoC?
  • What problem has the IoC solved?
  • The difference between IoC and DI?
  • What is AOP?
  • What problems does AOP solve?
  • Why is AOP called faceted programming?

First of all: IoC & AOP is not Spring’s idea. They actually existed before Spring, but were more theoretical then. Spring implements these two ideas well at the technical level.

What is the IoC

IoC (Inversion of control). It is an idea, not a technical implementation. Object creation and management in the Java development domain.

For example, existing class A depends on class B

  • The traditional way of development is to manually create an object of B in class A using the new keyword
  • Development using IoC thinking: instead of creating objects through the new keyword, the IoC container (the Spring framework) helps us instantiate objects. Which object we need can be passed directly from the IoC container.

In contrast, we “lose a right” (the right to create and manage objects) and gain a benefit (not having to worry about creating and managing objects, etc.)

Why is it called inversion of control

Control: Refers to the right to create (instantiate, manage) objects

Reverse: Transfer control to the external environment (Spring framework, IoC container)


What problem has the IoC solved

The idea of IoC is that two parties do not depend on each other and a third party container manages related resources. What’s the good of that?

  1. Less coupling or dependency between objects;
  2. Resources become easier to manage; For example, you can easily implement a singleton provided by the Spring container.

For example, there is an operation for User that is developed using a two-tier structure of Service and Dao

If the Service layer wants to use a concrete implementation of the Dao layer without using the IoC idea, You need to manually new the IUserDao implementation class UserDaoImpl in UserServiceImpl using the new keyword (you cannot directly new the interface class).


It’s perfectly possible, but let’s imagine the following scenario:

During development, a new requirement was suddenly received to develop another concrete implementation class for the IUserDao interface. Because the Server layer relies on the concrete implementation of IUserDao, we need to modify the object of new in UserServiceImpl. If only one class references the implementation of the IUserDao, it may be fine and not too hard to change, but if there are many places that reference the implementation of the IUserDao, it will be a headache to change the implementation of the IUserDao.

img

Using the IoC idea, we hand over control of objects (creation and management) to the IoC container, which we simply “ask” for when we use them

img

IoC and DI should stop being so stupid

The Inverse of Control is a design idea or a pattern. The idea is to give the Spring framework control over manually creating objects in your program. IoC is also used in other languages, not specific to Spring. IoC container is the carrier used by Spring to implement IoC. IoC container is actually a Map (key, value), which stores various objects.

The most common and logical implementation of IoC is called Dependency Injection (DI).

And a hopeful (Martin Fowler) in an article mentioned the name of the IoC to DI, the original text is as follows, the original address: https://martinfowler.com/articles/injection.html.

img

The gist of Ma’s statement is that IoC is so pervasive and meaningless that many people get confused by it, so it’s better to use DI to pinpoint the pattern.

What is the AOP

AOP is a continuation of OOP (Object-oriented programming).

Let’s start with an OOP example.

For example, there are three classes, Horse, Pig, and Dog, all of which have eat and run methods.

Horse, Pig, and Dog get eat() and run() automatically by inherits from Animal. This will save a lot of duplicate code.

img

OOP programming ideas can solve most code duplication problems. But there are some problems that can’t be dealt with. For example, OOP can’t solve the problem of repeating code in the same location of multiple methods in the parent Animal class.

/ * ** Animal parent class* /
public class Animal {

 / * * * / tall  private String height;   / * * * / weight  private double weight;   public void eat(a) {  // Performance monitoring code  long start = System.currentTimeMillis();   // Business logic code  System.out.println("I can eat...");   // Performance monitoring code  System.out.println("Execution Duration:" + (System.currentTimeMillis() - start)/1000f + "s");  }   public void run(a) {  // Performance monitoring code  long start = System.currentTimeMillis();   // Business logic code  System.out.println("I can run...");   // Performance monitoring code  System.out.println("Execution Duration:" + (System.currentTimeMillis() - start)/1000f + "s");  } } Copy the code

This part of the repeated code, generally referred to as crosscutting logic code.

img

Problems with crosscutting logic code:

  • Code duplication problem
  • Crosscutting logic code is mixed with business code, which is bloated and unmaintainable

AOP is designed to solve these problems

AOP takes a different approach and proposes a horizontal extraction mechanism to separate crosscutting logic code from business logic code

img

Breaking up the code is easy, but the hard part is how to silently apply the horizontal logic code to the original business logic without changing the original business logic.

What problems does AOP solve

Through the above analysis, it can be found that AOP is mainly used to solve: in the case of not changing the original business logic, enhance the cross-cutting logic code, fundamentally decouple, avoid cross-cutting logic code duplication.

Why is AOP called aspect oriented programming

Cutting: refers to the crosscutting logic. The original service logic code does not move and can only operate the crosscutting logic code. Therefore, it is oriented to crosscutting logic

Facets: Cross-cutting logic code tends to affect many methods, each of which is like a single point that forms a facet. There’s an idea of a face

This article is formatted using MDNICE