IOC starting example analysis

Raw data

1. Create a blank maven project

2. Write a UserDao interface first

public interface UserDao {
   public void getUser();
}

3. Write Dao's implementation class again

public class UserDaoImpl implements UserDao {
   @Override
   public void getUser() {
       System.out.println("Get user");
  }
}

4. Then write the UserService interface

public interface UserService {
   public void getUser();
}

5. Write the implementation class of Service again

public class UserServiceImpl implements UserService {
   private UserDao userDao = new UserDaoImpl();

   @Override
   public void getUser() {
       userDao.getUser();
  }
}

6. Test it

@Test
public void test(){
   UserService service = new UserServiceImpl();
   service.getUser();
}

7. Results

Question:
1. Add an implementation class of Userdao UserDao2Impl

public class UserDao2Impl implements UserDao {
   @Override
   public void getUser() {
       System.out.println("Get users in other ways");
  }
}

2. Then change the Service implementation class

public class UserServiceImpl implements UserService {
   private UserDao userDao = new UserDao2Impl();

   @Override
   public void getUser() {
       userDao.getUser();
  }
}

3. Then test
What if you add another implementation class UserDao3Impl??
Assuming that our demand is very large, this method is not applicable at all, and a lot of code needs to be modified every time we change The coupling of this design is so high that it will affect the whole body

How can we solve it?
Instead of implementing it, we can set aside an interface where we need it. Using set, we can modify it in the code

New way to realize data

Under ServiceImpl

public class UserServiceImpl implements UserService {
   private UserDao userDao;
// Using set
   public void setUserDao(UserDao userDao) {
       this.userDao = userDao;
  }

   @Override
   public void getUser() {
       userDao.getUser();
  }
}

test

@Test
public void test(){
   UserServiceImpl service = new UserServiceImpl();
   service.setUserDao( new UserDao2Impl() );
   service.getUser();
   //Now we want to implement it with UserDao3Impl
   service.setUserDao( new UserDao3Impl() );
   service.getUser();
}

This idea essentially solves the problem. Our programmers no longer manage the creation of objects, but pay more attention to the implementation of business The coupling is greatly reduced
This is the prototype of IOC!

If the above case is not clear enough, the following is another way to explain the underlying principle of IOC
---->XML + reflection + factory schema

The essence of IOC

The essence of IOC

The essence of IOC: inversion of control
Control) is a design idea.
In the original way, the creation of objects and the dependencies between objects are completely hard coded in the program. The creation of objects is controlled by the program itself. After the control is reversed, the creation of objects is transferred to a third party. The so-called inversion of control is to hand over the process of object creation and call between objects to Spring for management

IoC is the core content of the Spring framework. IoC is perfectly implemented in a variety of ways. You can use XML configuration or annotations. The new version of Spring can also implement IoC with zero configuration.

During initialization, the Spring container reads the configuration file first, creates and organizes objects according to the configuration file or metadata, and stores them in the container. When the program is used, it takes out the required objects from the Ioc container

Control reversal

Inversion of control is a way to produce or obtain specific objects through description (XML or annotation) and through a third party. In Spring, the IOC container implements control inversion, and its implementation method is dependency injection (DI). That is, the IOC idea is based on the IOC container, and the bottom layer of the IOC container is the object factory.

Bean management in IOC

① Bean management refers to two operations
Spring create object
Spring injection properties

② Bean can be implemented in two ways
Implementation of configuration file based on XML
Annotation based implementation

Bean management in IOC: when configuring beans in XML, the definition information of beans is separated from the implementation, and the annotation method can integrate the two. The definition information of beans is directly defined in the implementation class in the form of annotation, so as to achieve the goal of zero configuration.

Implementing beans using XML configuration

Click on the next blog!!!

Implementing beans using annotations

Click on the next blog!!!