Why use the beanFactory?

Mostly to understand coupling

We can look at a very simple case

A Web project can be divided into

  • Control layer
  • The business layer
  • Dao layer

If modules are developed according to layers, the control layer will depend on the business layer, and the business layer will depend on the DAO layer

If the code in the DAO layer changes, for example, if the previous class design was wrong and the class was changed, then the business layer will change

The same control layer may also have to change

So the connection between them is hard coded and too coupled

Now, in order to avoid that we need to program to interfaces, what functionality do we need to define in terms of interfaces in advance

So even if you change the class later but you don’t change the interface, you don’t change the function name, you don’t change anything, you don’t have to change a lot of code, right

However, at this time, there is a problem, the interface can not get the object, and we need to call these functions in fact, a new object, if only call the interface, can not effectively solve the problem

UserDaoImpl DAO = new UserDaoImpl() = UserDao dao = new UserDaoImpl()

However, the second half is still hard coded, the coupling is still too strong, and changes in the DAO layer will cause the business layer to change the code accordingly, so we can’t get objects in a new way

This is where the beanFactory comes in handy

We can write the full class name of the implementation class in the configuration file and then change it according to our configuration

Then let beanFactory get the parameters of the configuration file for us, and use reflection technology to get the corresponding object based on the full class name

For example, we could say in the configuration file

UserDao=com.kehao.UserDaoImpl1
Copy the code

So if we just give beanFactory an interface, it can find out which implementation class it is, and then it can get the corresponding object, which solves the coupling problem between them

This configuration file can be modified after the project is deployed, so even if the DAO layer changes, only the corresponding configuration file needs to be modified, and the business layer does not need to change any coding at all, to successfully realize the coupling

This is known as inversion of control

A simple example

  • interface
public interface Animal {
    void shout(a);
}
Copy the code
  • The implementation class

Cat

public class Cat implements Animal {
    @Override
    public void shout(a) {
        System.out.println("Meow meow!!"); }}Copy the code

Dog

public class Dog implements Animal{
    @Override
    public void shout(a) {
        System.out.println("Woof woof!!"); }}Copy the code
  • The realization of the BeanFactory
public class MyBeanFactory {

    public static  <T> T newInstance(Class<T> tClass)  {
        ResourceBundle bundle = ResourceBundle.getBundle("impl");
        String animal = bundle.getString("Animal").trim();
        T t = null;
        try {
            t = (T) Class.forName(animal).newInstance();
        }catch (Exception e){
            e.printStackTrace();
        }
        returnt; }}Copy the code
  • The properties file
Animal=kehao.others.Cat 
Copy the code
  • The main function
public class Main {

    public static void main(String[] args) { Animal animal = MyBeanFactory.newInstance(Animal.class); animal.shout(); }}Copy the code

This is just a record of the idea, and the real use can be made directly from the Spring framework