Spring的IOC到底有什么好处：设计模式3——从工厂模式到IOC_有了ioc 工厂模式还有什么意义?-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_41788977/article/details/107434206

文章目录

日常开发场景

在Web程序中一个常见的场景：
商城提供了商品查询服务，查询需要使用datasource来查询信息，datasource又需要使用Properties来获取配置

现在尝试使用new来创建对应的数据源及配置实例，提供查询商品信息的服务：

/**
* 商品信息服务
**/
public class ItemServiceImpl implements ItemService{
    // 使用new 来实例化配置类，从项目路径获取数据源相应配置
 private ConfigProperties config = new ConfigProperties("xxx.xml");
 // 实例化dataSource 不得不先实例化config
 private DataSource dataSource = new DataSource(config);
 
 @Override
 public ItemInfo seleteitemList(int page,int pageSize,Param param){
  ...
  // 使用dataSource 查询商品数据
  List<Item> items = dataSource.selectList(page,pageSize,param);
  ...
  return result;
 }
}

现在，商城的会员服务同样需要用到dataSource ，相同的new代码需要写到PersonService

/**
* 会员信息服务
**/
public class PersonServiceImpl implements PersonService{
    // 相同的依赖再次实现 
 private ConfigProperties config = new ConfigProperties("xxx.xml");
 private DataSource dataSource = new DataSource(config);
 
 @Override
 public PersonInfo seleteitemList(int page,int pageSize,Param param){
  ...
  // 使用dataSource 查询商品数据
  List<Person> pers = dataSource.selectList(page,pageSize,param);
  ...
  return result;
 }
}

每次需要数据源和配置的地方都需要使用new来实例化对象

突然有一天，ConfigProperties 需要构造中传入编码支持中文字符了，在一个一个服务改…
突然有一天，DataSource不需要依赖Config了，从一个一个服务代码中删除…

（注：可能会想到为什么不把数据源和配置抽成全局的，一个一个new是不是太傻了，现实情况是不一定是直接new数据源，new配置，而可能是 service依赖 mapper,controller 依赖 service，，，但是代码为了演示new带来的耦合问题，所以new的是什么就不重要了。）

使用new来实例化组件带来的问题

直接使用new带来的缺点：

实例化过程复杂：每一个组件的实例化都需要了解构造方法，组件间的依赖关系需要依赖者关注。
组件的共享困难：多个依赖者可能依赖同一个组件实例，那么缺乏一个“管理者”管理这个可以共享的Bean。
依赖者新增组件时，会使原有的组件依赖变得更加复杂，违背了开闭原则。依赖者与组件间依赖，组件之间相互依赖，耦合度高。试想如果因为一个组件的构造方法改变，很可能会牵一发而动全身——需要修改所有依赖它的依赖者的代码。
组件生命周期管理困难，没有机制控制这个组件何时产生何时销毁。组件在销毁时，无法保证销毁顺序
测试组件困难，如果一个service依赖了mysql的datasource，那么想要测试这个service,必须提供真实的mysql数据库环境，无法替换。（依赖的是细节而不是抽象）。

工厂模式

针对组件对象实例化过程的复杂，首先可以使用工厂设计模式来解决对象的创建问题，简单工厂模式：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。

我们可以定义一个全局Bean工厂，由它来实例化所有需要它来管理的类：

public class BeanFactory{
    // 实现一个简单的bean 缓存池，缓存由工厂生成的Bean 对象
    private Map<String,Object> contains = new HashMap<>(1024);
    
    public static Object getFactoryBean(String beanName){
        
        Object result = getContainsBeanOrNull(String beanName);
        if(result != null){
            return result;
        }
        
        if("dataSourceConfig".equals(beanName)){
            contains.put(beanName,new ConfigProperties("xxx.xml"));
            return contains.get(beanName);	
        }else if("dataSource".equals(beanName)){
            Object config = contains.get("dataSourceConfig");
            if(config == null){
                contains.put(beanName,new ConfigProperties("xxx.xml"));
            }
           contains.put(beanName,new DataSource(config));
           return contains.get(beanName);
        }
    }
    
    private static Object getContainsBeanOrNull(String beanName){
        if(contains.contains(beanName)){
            return contains.get(beanName);
        }else{
         	return null;   
        }
    }
    
}

这样我们在需要数据源对象的时候，只需要BeanFactory.getFactoryBean(“XXX”); 即可。

当然上边的模式只是工厂模式中的简单工厂模式，在 GoF 所著的《设计模式》一书中，简单工厂模式被划分为工厂方法模式的一种特例，没有单独被列出来。

上述简单的工厂模式实现可以把对象的构建构成放到一个统一的全局工厂中，这样就把组件的创建和使用分离开来，但缺点也明显，工厂每增加一种类型的对象，就需要修改工厂代码——违反开闭原则，客户端虽然不需要知道怎么构建数据源了，但是需要知道工厂能创建那种对象。（在Spring中，Bean声明可以放到xml中，也可以使用注解声明，这一点间接解决了这个问题，声明它->使用它）

除了简单工厂模式，工厂模式还包含工厂方法模式及抽象工厂模式。

工厂方法模式中，定义了抽象工厂与生产抽象产品的方法，然后由具体的工厂子类来决定生产哪一种具体产品

在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责哪一个产品类被实例化这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。

工厂方法模式与简单工厂模式的区别在于：不再由一个工厂负责生产多种类型的实例，因为这样违背了"一个类应该仅有一个令它变化的原因"。

具体到代码层面，配置类ConfigProperties应该由ConfigFactory的实例负责生产

/**
* 专门负责生产配置的工厂 
**/
public interface ConfigFactory{
    // Config 也不再是具体的类 而应该是抽象类或者接口 代表ConfigFactory工厂的产品是一些列
    // 类型为Config 的子类
    Config getConfigInstance();
}

/**
* 定义配置类公有的行为方法：设置配置键值，获取配置键值
这样做的好处是，Config不再局限于文件配置，还可以是Redis配置、HashMap存放的本地配置等等，只要配置类实现了Config接口，就可以被ConfigFactory 生产出来
**/
interface class Config{
    void put(String key,Object value);
    Object get(String key);
}

/**
* 类的实现比较详细，但不要陷入细节当中，重点关注这个类与前面dataSource需要的Config相对应
  写出类是为了更好的结合本文的主题--工厂设计模式
**/
class ConfigProperties implements Config{
    private String filePath = "classpath:XXX.properties";
    @Override
    public void put(String key,Object value){
        // 对于文件配置来说，put方法可能是不常用的，因为配置文件存在即是为了将配置统一的放在一个文件中
        // 如果是在运行中put 显然有点违背了这一设计目的，但是不要紧，有些情况下也会需要临时写一个配置
        // 放到文件中。如果是redis等配置源可能此方法就比较普遍使用了
        Properties pps = new Properties();
        InputStream in = new FileInputStream(filePath);
        //从输入流中读取属性列表（键和元素对） 
        pps.load(in);
        //调用 Hashtable 的方法 put。使用 getProperty 方法提供并行性。  
        //强制要求为属性的键和值使用字符串。返回值是 Hashtable 调用 put 的结果。
        OutputStream out = new FileOutputStream(filePath);
        pps.setProperty(key, value.toString());
        //以适合使用 load 方法加载到 Properties 表中的格式，  
        //将此 Properties 表中的属性列表（键和元素对）写入输出流  
        pps.store(out, "Update " + pKey + " name");
        
        //注意：以上过程不重要哈，本文的重点还是设计模式，贴出来有点印象就行
    }
    @Override
    public Object get(String key){
        Properties pps = new Properties();
        try {
            InputStream in = new BufferedInputStream (new FileInputStream(filePath));  
            pps.load(in);
            String value = pps.getProperty(key);
            System.out.println(key + " = " + value);
            return value;

        }catch (IOException e) {
            e.printStackTrace();
            return null;
        }
    }
}

ConfigFactory 定义出来之后，我们可以写它的实现来解决我们之前的问题了，回顾，之前使用new的方式来实例化组件，带来了实例化过程复杂和实例难以共享的问题，使用简单工厂模式定义一个全局的既当爹又当妈的工厂来解决了这个问题，但是在实际应用中，简单工厂模式的简单二字也带来了后期的维护隐患，使用工厂设计模式我们试图实现：新增一类实例，不再需要改变原有结构，而是通过定义工厂接口来生产特定类型的实例。

public class PropertiesConfig implements ConfigFactory{
    private ConfigProperties configProperties = new ConfigProperties();
    private static final PropertiesConfig PROPERTIESCONFIG = new PropertiesConfig();
    // 用单例来改造下，全局拥有PropertiesConfig合情合理
    // 不用纠结实现的方式，改天我们总结下--最完美的单例模式是哪种？
    private PropertiesConfig(){}
    public static PropertiesConfig getIncetance(){
        return PROPERTIESCONFIG;
    }
    @Override
    public Config getConfigInstance(){
        // 简单粗暴 恶汉的方式直接声明configProperties，然后返回
        return configProperties;
    }
}

看起来不错，数据源也使用同样方式处理之后，我们就用工厂方法模式改造了之前的耦合结构，但是注意，我们使用的时候：

...
    Config config = PropertiesConfig.getIncetance().getConfigInstance();
	DataSourceFactory DataSourceFactor = MySqlDataSource.getIncetance().getDataSourceInstance(config);
...

看起来似乎更复杂了。。。这样每次新增一个依赖还要写那一堆工厂。。。

答案是：确实是，但是组件的生产与使用的分离确实降低了耦合，当工程一大再大，它的价值就会越来越明显，关于编写复杂的问题，是可以通过一系列手段去简化的，比如后边说到的IOC，其实IOC更像简单工厂模式的高级版，包含了实例管理，依赖注入，生命周期等等功能。

工厂设计模式还剩最后一个：抽象工厂模式

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

抽象工厂与工厂方法模式的区别在于：工厂方法模式在横向上对产品进行拓展，每个工厂负责单一的产品类型的生产，而抽象工厂是对产品的纵向上进行扩充，每个工厂可以负责一系列产品族的生产。

关于抽象工厂模式实现细节，因为与本文的主题偏离不再贴代码了，可以参考图说设计模式

引入IOC

回到主题：IOC到底好在哪里？通过工厂模式我们可以看出来，组件的创建与使用分离给代码结构带来了极大的改观，工厂的存在，将依赖的控制权转移到了工厂中，这一设计理念正是IOC的核心价值体现，它解决了这样一组核心问题：

谁来创建组件
谁来按照依赖管理组装组件
谁来按依赖顺序销毁组件

答案就是IOC容器，它就是一个大工厂。

我们需要一个Bean只需要声明它的构造过程，在使用时注入即可，由spring容器来管理Bean带来的好处是

依赖一个组件时，不需要了解组件的创建方式创建过程，拿来即用。好莱坞法则（Don’t call us, we’ll call you）
组件共享非常容易
测试组件时，不再必须提供真实环境，可以使用内存数据库替换mysql数据库，因为依赖的不是mysql而是dataSource，内存数据库也是一种dataSource。

IOC 解决的核心问题是：将组件的创建和组装与组件的使用相分离，并且由IOC容器管理组件的生命周期。

Spring的这一设计，几乎成为了框架粘合剂，引入一个新的框架，都可以将Bean交由Spring统一管理，回顾下MyBatis 的引入过程，你一定记得在一个配置文件中配置了SqlSessionFactoryBean, MyBatis通过Spring来管理生产SqlSession的SqlSessionFactory，每一个SqlSession开启一个数据库连接…

总结

工厂模式将实例的生产与使用相分离，使对象的生产方式不再影响客户端使用，降低了耦合
工厂模式分为简单工厂模式、工厂方法模式、抽象工厂模式
其实Integer n = Integer.valueOf(100); 可以称为静态工厂方法，好处是-127~128的实例可以复用
IOC 一个Spring旗下的大工厂，提供了Bean的生命周期管理，IOC容器的出现，解决了组件之间错综复杂的依赖关系，并且这一特性，使Spring成为框架粘合剂提供了可能。