coupling
Baidu Encyclopedia:
Coupling is also called inter-block connection, which refers to a measure of the closeness of interconnection between modules in the software system structure. The closer the connection between the modules, the stronger the coupling, and the more independent the modules, the worse.
Coupling
in Java: For example, in web development, the presentation layer needs to hold the objects of the business layer, and the business layer needs to hold the objects of the persistence layer. This relationship is a strong dependency.
The code is as follows:
business layer: (under package service)
package top.radish.service
public class AccountService {
// 持久层的AccountDao对象
private AccountDao accountDao = new AccountDao();
public void saveAccount(Integer num) {
accountDao.saveAccount(num)
}
}
Persistence layer: (under dao)
package top.radish.dao
public class AccountDao {
public void saveAccount(Integer num) {
// 保存到数据库
}
}
Explanation:
The AccountService class holds an instantiated object of the AccountDao class. This combination relationship has a dependency relationship, that is, there is a coupling.
Explained with images as follows:
Disadvantages of high coupling:
- Chain reaction, if one module is modified, multiple modules need to be modified
-when the tag name of AccountDao is modified to, all classes in the business layer that hold instance objects of AccountDao need to be modified. If AccountDao is changed to AccountDao1, then all private accountDao = new AccountDao() of the business layer must be changed to private accountDao = new AccountDao1() . When there are too many such types in the business layer, it takes a lot of time to modify. - Due to the dependencies between modules, the combination of modules will require more effort and time
Decoupling
High coupling has many disadvantages, so it is necessary to find a way to reduce the degree of coupling.
Decoupling ideas
- Step 1: Need a configuration file to configure our service and dao (configuration file can choose xml or properties)
- Part 2: Read the configuration file and create objects through reflection
Simple implementation of decoupling.
- The configuration file used here is properties (spring used xml+dom4j)
- Reflection needs to know the fully qualified class name of the class
Configuration file: bean.properties
// 其中accountDao为自己定义的名称，top.radish.dao.AccountDao为全限定类名
accountDao=top.radish.dao.AccountDao
Create a factory for object production: (This is not a factory mode)
package top.radish.factory
/**
*对象生产工厂（这里就不进行异常的处理了）
*/
public class BeanFactory {
private static Properties pros;
static {
pros = new Properties();
// 加载配置文件
InputStream in = BeanFactory.class.getClassLoader().getResourceAsStream("bean.properties");
pros.load(in);
}
// 生产bean对象
public static Object getBean(String beanName) {
// 获取类的权限定类名
String path = pros.getProperty(beanName);
// 通过反射创建对象
Object value = Class.forName(beanPath).newInstance();
return value;
}
}
Modify the business layer code:
package top.radish.service
public class AccountService {
// private accountDao = new AccountDao();
// 修改为：
private AccountDao accountDao = (AccountDao)BeanFactory.getBean("accountDao");
public void saveAccount(Integer num) {
accountDao.saveAccount(num)
}
}
Illustrate the above code: The
factory provides the business layer with instance objects of the persistence layer through the configuration file, which reduces the coupling relationship between the business layer and the persistence layer. E.g. AccountDao tag name to AccountDao1 , the profiles only need to fully qualified name of the class top.radish.AccountDao modify top.radish.AccountDao1 modified to complete the code, the code does not require extensive modifications to the business layer, This saves time in code maintenance.
to sum up
- The factory is not the factory pattern in the design pattern
- In the spring framework, configuration files are read through dom4j+xml.
- The coupling cannot be completely eliminated, it can only be reduced.
There is something wrong, please correct me