前言
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.csdn.net/zhangyuxuan2/article/details/83007830