Understand Spring IOC concepts and how to reduce code coupling

Understand Spring IOC concepts and how to reduce code coupling

1. What is IOC

IOC (Inversion of Control) Inversion of Control is an important feature in spring and a design principle in object-oriented programming, which can be used to reduce the coupling between computer codes. So the right to control what has been reversed? We know that in the process of writing code, there is often a dependency relationship between two objects. When object A depends on object B, we usually pass new in object A. way to create its dependent object B, and after the inversion of control, the right to create the object is entrusted to the IOC container, that is, these objects are generated by the container, rather than the object creating its own dependent objects when needed .

For example, to understand IOC, the formation of a family requires two husbands and wives. In a sense, we can say that there is a dependency between the two. The traditional way is that when I need to form a family, I go to find a partner and start a family by myself, but the IOC way is to delegate the right to find a partner to my parents. When I was born, my parents pointed out my belly. For marriage, find a good partner for me.

How two IOCs reduce the coupling between codes

Step-by-step decoupling from traditional methods to IOC

2.1 The first step is to transform the direct new object ----> interface-oriented programming

In the beginning, we created an object in the way of new object, but this cannot achieve polymorphism. For example, if I create a person object, which has an eat (Apple apple) method, then the class that calls this eat method needs to pass in apple (Apple) object, then my method was changed to eat pears, and this method was changed to eat(Pear pear), and the class that called the eat method needed to change the previous apples to pears, which had poor scalability, so it appeared. For interface-oriented programming, I pass in the Fruit interface in the eat method. After that, apples and pears only need to implement the interface. The class that calls the eat method, if you want to eat pears, you can pass in pears, and if you want to eat apples, you can pass in apples. .

2.2 The second step is to change interface-oriented programming -----> Factory mode

After interface-oriented programming, the coupling between the interface and the implementation class is solved. In interface
-oriented programming, we often have such code UserDao userDao = new UserDaoImpl(); Suppose this UserDaoImpl is no longer used, and another implementation class of UserDao is used instead. UserDaoImpl2, UserDao userDao = new UserDaoImpl() needs to be changed to UserDao userDao = new UserDaoImpl2(), which means that the interface and the implementation class are coupled.

How does the factory pattern solve the coupling problem? Instead of letting the interface and the implementation class have a relationship, find a middleman, that is, the factory, and the implementation class must be taken out of the factory. The meaning of a factory is a class that mass-produces the same specification (specification is the good specification provided by the interface class).
Factory class:

class BeanFactory {
    
    
    public static UserDao getUserDao() {
    
    
        return new UserDaoImpl();
    }
    public static StudentDao getStudentDao() {
    
    
        return new StudentDaoImpl();
    }
}

UserDao userDao = new UserDaoImpl —> UserDao userDao = BeanFacotry.getUserDao();
StudentDao studentDao = new StudentDaoImpl ----> StudentDao studentDao = BeanFacotry.getStudentDao(); In
this way, if userDao becomes need UserDaoImpl1, studentDao becomes Need StudentDaoImpl1, I just need to go to BeanFactory to change the corresponding getUserDao and getStudentDao methods. This is actually changing from changing multiple classes to changing a method of BeanFacotry, so that the interface class and the factory class are coupled.

2.3 The third step is to transform the factory mode ----> factory mode + reflection + configuration file (the underlying implementation of IOC)

In order to solve the coupling between the interface class and the factory class, is it necessary to solve the problem?

public static UserDao getUserDao() {
    
    
    return new UserDaoImp();
}

This method can only return UserDaoImpl or UserDaoImpl1. We hope that he can return the required UserDaoImpl according to our needs. How to solve it?
Configuration xml file - specify the UserDaoImpl that needs to be returned

<bean id="userDao" class="**.UserDaoImpl">

Factory class

class BeanFactory {
    
    
    public static UserDao getUserDao(String id) {
    
    
        // String className = 解析配置文件xml 拿到id对应的class
        // 反射
        class clazz = class.forName(className);
        return clazz.newInstance();
    }
}

In this case, if we need to change the type of the implementation class of UserDao, we can modify it directly in the configuration file without changing the code!

Three DI concepts in Spring

DI: Dependency injection, the premise is that there must be an IOC environment. When Spring manages this class, it injects the properties of class dependencies into it
. When we write code, we know that there are often dependencies between objects and objects. When we use After IOC gives the right to create an object to spring, spring must also create the corresponding dependencies of the object when creating the object, otherwise the object created is an object with imperfect functions, then the process of dependency injection is it Another feature of DI (Dependency Injection)

---

Author
: sour sour sauce