怎么基于Spring使用工厂模式实现程序解耦

这篇文章将为大家详细讲解有关怎么基于Spring使用工厂模式实现程序解耦，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

在高明等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都做网站、网站建设、外贸营销网站建设 网站设计制作定制设计,公司网站建设,企业网站建设,成都品牌网站建设,全网营销推广,外贸营销网站建设,高明网站建设费用合理。

这篇文章主要介绍了如何基于Spring使用工厂模式实现程序解耦,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下

1、 啥是耦合、解耦？

既然是程序解耦，那我们必须要先知道啥是耦合，耦合简单来说就是程序的依赖关系，而依赖关系则主要包括

1、 类之间的依赖

2、 方法间的依赖

比如下面这段代码：

public class A{    public int i;  }  public class B{    public void put(A a){      System.out.println(a.i);    }  }

上面这个例子中A类和B类之间存在一种强耦合关系，B类直接依赖A类，B类的put方法非A类类型不可，我们把这种情况叫做强耦合关系。

实际开发中应该做到：编译期不依赖，运行时才依赖。怎么理解呢？我们很容易想到多态向上转型，是的，编译时不确定，运行时才确定,当然接触面更广一点的童鞋会想到接口回调，是的接口回调方式也能有效的解耦！如下代码：

//一个接口叫做Inter，里面定义了一个happy（）方法，有两个类A、B实现了这个接口interface Inter{  void happy();}class A implements Inter{  @Override  public void happy() {    System.out.println("happy...A");  }}class B implements Inter{  @Override  public void happy() {    System.out.println("happy...B");  }}public class Test{  public void happys(Inter inter){    inter.happy();  }}

是的，如上代码正是典型的接口回调，Test类中的happys方法参数变的相对灵活起来，代码中Test类与A类、B类之间就存在一种弱耦合关系，Test类的happys方法的参数可以使A类类型也可以是B类类型，不像强耦合关系中非A类类型不可的情形。

从某一意义上来讲使用类的向上转型或接口回调的方式进行解耦都是利用多态的思想！

当然解耦的方式还有很多，从根本意义上讲实现低耦合就是对两类之间进行解耦，解除类之间的直接关系，将直接关系转换成间接关系，从而也有很多设计模式也对程序进行解耦，比如：适配器模式、观察者模式、工厂模式....总之，必须明确一点：耦合性强的程序独立性很差！

2、 jdbc程序进行解耦

先来看一段代码：

//1、注册驱动DriverManager.registerDriver(new com.MySQL.jdbc.Driver()); //如果把jdbc的MySQLjar包依赖去除直接编译失败提示没有mysql  //2、获取连接Connection conn=DriverManager.getConnection("jdbc:mysql://localhost:3306/ufida","root","root");//3、获取操作数据库的预处理对象PreparedStatement pstm=conn.prepareStatement("select * from client");//4、执行SQL，得到结果集ResultSet rs=pstm.executeQuery();//5\遍历结果集while(rs.next()){  System.out.println(rs.getString("name"));}//6、释放资源rs.close();pstm.close();conn.close();

等等等等，好熟悉好怀念的代码.....

没错就是jdbc的代码，不是用来怀旧的，而是如果这样设计，你会觉得这样的程序耦合性如何？又如何进行解耦？先仔细思考一番。

一分钟过去了.....

两分钟过去了.....

好了，我们都知道jdbc连接MySQL需要一个mysql-connector的jar包，如果我们把这个jar包依赖或者这个jar包给去掉，显然上面的这个程序会编译报错，如下图

显然这样的程序耦合性过高！于是我们可以这样设计，将第一步的注册驱动代码new的方式改成反射的方式如下：

//1、new的方式注册驱动DriverManager.registerDriver(new com.mysql.jdbc.Driver()); //如果把jdbc的MySQLjar包依赖去除直接编译失败提示没有mysql相关的jar包改为如下方式 //2、反射的方式注册驱动Class.forName("com.mysql.jdbc.Driver"); //改用这种方式注册驱动会发现不会编译失败，相比上面的方式相对解耦，但是依然存在缺陷：若连接改为Oracle数据库，这里的字符串又要进行改动！

正如注释的解释一样，又一个缺陷就浮现了：若连接改为Oracle数据库，这里的字符串又要进行改动！

于是对于这个jdbc程序来说就有这样的一个解耦思路：

第一步：通过反射来创建对象，尽量避免使用new关键字

第二步：通过读取配置文件来获取创建的对象全限定类名

3、传统dao、service、controller的程序耦合性

顺着jdbc程序的解耦思路，我们再来看看传统dao、service、controller的程序耦合性分析

由于只是一个demo，省去dao层的操作.....

定义一个Service接口

public interface IAccountOldService{  public void save();}

Service接口实现类

public class AccountServiceOldImpl implements IAccountOldService{  @Override  public void save() {    System.out.println("save成功一个账户....");  }}

controller代码：

public class AccountCencollertOld {  public static void main(String[] args) {    IAccountOldService iaccount=new AccountServiceOldImpl ();     iaccount.save(); //运行结果：save成功一个账户....  }}

到这里，有何想法？表面上来看是没有一点问题的，So Beautiful，但仔细的看。表现层与业务层、业务层与持久层紧紧的互相依赖关联，这与我们开发程序的高内聚低耦合原则相违背,哦My God,So Bad！我们顺着jdbc程序的解耦思路，我们应该尽量避免使用new关键字，我们发现这些层里面service层new 持久层dao，controller表现层new 业务层service....太糟糕了

那么对此，你有何解耦思路？

4、使用工厂模式实现解耦

别想了，工厂模式实现程序解耦你值得拥有！顺着jdbc程序的解耦思路：

1、通过读取配置文件来获取创建的对象全限定类名2、通过反射来创建对象，尽量避免使用new关键字

首先在resources目录下中写一个bean.properties配置类，具体内容如下

accountServiceOld=com.factory.service.impl.AccountServiceOldImpl

接着使用工厂方法代码：

/** * 一个创建Bean对象的工厂 * *  1、需要一个配置文件来配置我们的service和dao  配置文件的内容：唯一标识=全限定类名（key-value） *  2、通过读取配置文件中配置的内容，反射创建对象 * *  场景：主要是service调用dao，controller调用service的程序。这里面耦合性非常的高，互相new互相依赖 * *  为了解耦，利用工厂模式进行 */ public class BeanFactoryOld {  private static Properties props;  static{    try {      //实例化对象      props = new Properties();      //获取properties文件的流对象      InputStream in = BeanFactory.class.getClassLoader().getResourceAsStream("bean.properties");      props.load(in);//加载其对应路径下的配置文件    }catch (Exception e){      throw new ExceptionInInitializerError("初始化properties失败！");    }  }  //根据bean的名称获取bean对象  public static Object getBean(String beanName){    Object bean=null;    try {    String beanPath= props.getProperty(beanName);    bean = Class.forName(beanPath).newInstance();  //这里的newInstance创建实例（默认无参构造器）每次执行都需要创建一次    } catch (Exception e) {      e.printStackTrace();    }    return bean;  }}

此时，controller的代码就可以编写为

/** * 这里模拟一个controller调用service * */public class AccountCencollertOld {  public static void main(String[] args) {  //  IAccountOldService iaccount=new AccountServiceOldImpl (); //使用工厂方法不再通过new方式    IAccountOldService iaccount= (IAccountOldService) BeanFactoryOld.getBean("accountServiceOld");    iaccount.save(); //运行结果：save成功一个账户....  说明成功调用了service  }}

通过运行结果，属实没毛病，成功降低程序耦合！So Beautiful！先高兴一会吧，因为马上出现.....但是，随之而来的问题又出现了，我们对这个controller进行一下改写

for(int i=0;i<5;i++){    IAccountOldService iaccount= (IAccountOldService) BeanFactoryOld.getBean("accountServiceOld");    iaccount.save();    }

打印结果：

com.factory.service.impl.AccountServiceImpl@1540e19dsave成功一个账户....com.factory.service.impl.AccountServiceImpl@677327b6save成功一个账户....com.factory.service.impl.AccountServiceImpl@14ae5a5save成功一个账户....com.factory.service.impl.AccountServiceImpl@7f31245asave成功一个账户....com.factory.service.impl.AccountServiceImpl@6d6f6e28save成功一个账户....

打印的是五个不同的对象，说明是多例的，每次调用getBean的时候都会newInstance出一个新对象，如下

多例每次都要创建对象，资源浪费、效率低下

针对单例多例情况，我们再对service业务层代码进行修改：

public class AccountServiceImpl implements IAccountService {  //定义类成员  private int i=1;   @Override  public void save() {    System.out.println("save成功一个账户....");    System.out.println(i);    i++;  }}

运行controller代码，运行结果

save成功一个账户....1save成功一个账户....1save成功一个账户....1save成功一个账户....1save成功一个账户....1

why？多例因为每次都是新的对象，上面也验证过了，因此每次创建新对象都会初始化一次，重新赋值，所以都是1，如果我们把类成员改为局部成员变量如下

public class AccountServiceOldImpl implements IAccountOldService {//  private int i=1;   @Override  public void save() {    int i=1;  //改为局部变量    System.out.println("save成功一个账户....");    System.out.println(i);    i++;  }}

不用猜，运行结果同样是1。算了还是运行一下吧哈哈哈

save成功一个账户....1save成功一个账户....1save成功一个账户....1save成功一个账户....1save成功一个账户....1

说了这么多，通过观察service和dao之间单不单例好像无所谓，因为他们之间并没有业务方法中改变的类成员，所以并不需要多例来保证线程安全。那说这些有何意义？不要忘了，由于使用了工厂改进如下中的.newInstance创建实例（默认无参构造器）每次执行都需要创建一次，这样就不好了（浪费资源），因此我们要设计出只newInstance创建一次实例就很完美了，这也是我为啥要在service和controller中都添加一个Old关键字的原因了，接下来我们来看看工厂是如何改进的！

5、工厂模式改进

为了不被搞晕，我们重新写代码，也就是重头开始写代码~其实就是把Old去掉~

由于只是一个demo，省去dao层的操作.....

定义一个Service接口

public interface IAccountService {  public void save();}

Service接口实现类

public class AccountServiceImpl implements IAccountService{  @Override  public void save() {    System.out.println("save成功一个账户....");  }}

controller代码：

/** * 这里模拟一个controller调用service * */public class AccountCencollert {  public static void main(String[] args) {//    IAccountService iaccount=new AccountServiceImpl();     IAccountService iaccount= (IAccountService) BeanFactory.getBean("accountService");    iaccount.save(); //运行结果：save成功一个账户....  说明了成功调用了service   } }

改进的工厂方法代码：

public class BeanFactory {  private static Properties props;  //定义一个map容器，用于存放创建的对象  private static Map beans; //改进的代码============  static{    try {      //实例化对象      props = new Properties();      //获取properties文件的流对象      InputStream in = BeanFactory.class.getClassLoader().getResourceAsStream("bean.properties");      props.load(in);//加载其对应路径下的配置文件      ////////////////////以下是改进的代码=======================      //实例化容器      beans=new HashMap();      //取出配置文件中所有的key值      Enumeration