Spring学习（三）—— 面向接口编程-＞工厂模式-＞Spring

前言

java学习记录：面向接口编程（内容为转载）

---

一：面向接口编程

阿轩打算教儿童背古诗，用Java描述应该是这样：

class Child{//儿童
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Teacher{//老师
    public void teach(Child child){}//教课
}
/*这就是标准的面向对象编程，描述了对象间的关联。*/

后来业务熟练了，打算扩展服务对象，增加在校学生，代码就变成了这样：

class Child{//儿童
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Student{//学生
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Teacher{//老师
    public void teach(Child child){}//教儿童背古诗
    public void teach(Student student){}//教学生背古诗
}
/*这还是标准的面向对象编程，但是不具备扩展性*/

后来继续扩展服务对象，增加外国人，这下老师又要研究新的业务？不如一步到位，提前掌握更宽泛的技能，代码如下：

abstract class Person{//人
    public abstract void listen();//听课
    public abstract void recite();//朗读
}
class Child extends Person{//儿童
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Student extends Person{//学生
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Foreigner extends Person{//外国人
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Teacher{//老师
    public void teach(Person person){}//教人背古诗
}
/*这就对面向对象编程进行了更深入的应用，具备了一定的扩展性，称为面向基类编程，通常基类会被声明为抽象类，
所以又称面向抽象类编程*/

按照以前的经验，估计业务又要扩展了，不过即使再出现新的服务对象类型，只要是人，阿轩都可以应付。但是这次又有问题了，新的服务对象又来了：鹦鹉，现有的技能不匹配了。如果继续加宽服务对象范围为动物，很多动物又没办法服务，那怎么称呼这些服务对象呢？算了，不管这些对象是什么，我只需要考虑他们能干什么就好了。于是代码变成了这样：

public interface ListenAndReciteAble{//能听会读的
    void listen();//听课
    void recite();//朗读
}
abstract class Person implements ListenAndReciteAble{//人
}
class Child extends Person{//儿童
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Student extends Person{//学生
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Foreigner extends Person{//外国人
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Parrot implements ListenAndReciteAble{//鹦鹉
    public void listen(){}//听课
    public void recite(){}//朗读
}
class Teacher{//老师
    public void teach(ListenAndReciteAble lar){}//教背古诗
}
/*要让一个依赖方达到最大的兼容性或扩展性，就要让依赖的对象类型尽量宽泛，当然Object是最宽泛的，
但是这就不明确了，而且不能保证依赖方的需要。这是就要跳出一些定式，我需要什么的是什么？
还是我需要的是他们会什么？这就变成了面向接口编程。*/
谢谢

---

原文地址：http://www.imooc.com/article/details/id/20829

二：工厂模式

面向接口编程后，用工厂模式来解决接口和实现类之间的耦合。
在面向接口编程中我们常常会出现这样的代码UserDao userDao = new UserDaoImpl(); 假设现在不用这个UserDaoImpl了，而改用UserDao的另一个实现类UserDaoImpl2，UserDao userDao = new UserDaoImpl()需要改为UserDao userDao = new UserDaoImpl2()，这样也就是接口和实现类出现了耦合。

工厂模式如何去解决耦合问题呢 ---- 不让接口和实现类产生关系，而是找一个中间人，也就是工厂，实现类必须要从工厂中取出来。工厂的意思也就是一个批量制造同样规格(规格也就是接口类所提供好的规范)类的类。

工厂类：

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();
这样的话，如果userDao变成了需要UserDaoImpl1，studentDao变成了需要StudentDaoImpl1，我只需要去BeanFactory中改对应的getUserDao和getStudentDao方法即可。这样实际上就是从改多个类变成了改BeanFacotry一个方法，这样接口类和工厂类产生了耦合

三：工厂模式+反射+配置文件(IOC的底层实现)

为了能解决接口类和工厂类的耦合，是不是也就是要解决工厂类方法中只能返回UserDaoImpl或者UserDaoImpl1的问题，我们希望他可以根据我们的需要返回需要的UserDaoImpl，如何解决？

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

解决方法：Spring方式，配置xml文件 — 指定需要返回的UserDaoImpl

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

工厂类：

class BeanFactory {
    public static UserDao getUserDao() {

        // 1. 使用ClassPathXmlApplicationContext创建 Spring 的 IOC 容器
		ApplicationContext beanConfig = new ClassPathXmlApplicationContext("spring-config.xml");
		// 2. 从 IOC 容器中获取 bean 的实例
        return (UserDao)beanConfig.getBean("CustomerService");
        //return beanConfig.getBean("CustomerService",UserDao.class);
    }
}

这样的话如果我们需要改UserDao的实现类的类型，我们可以直接在配置文件中修改，就不用改代码啦！

Spring中DI概念

DI：依赖注入，前提是必须要有IOC的环境，Spring管理这个类的时候将类依赖的属性注入进来
我们在写代码的时候知道，对象和对象之间经常会存在依赖关系，当我们使用了IOC将对象的创建权交给spring之后，spring在创建对象的同时一定也要将对象相应的依赖同时创建好，否则创建的这个对象就是一个功能不完善的对象，那么依赖注入的这个过程就是它的另一个特性DI(依赖注入)
————————————————
原文链接：https://blog.youkuaiyun.com/zhangyuxuan2/article/details/83007830