设计模式学习笔记 接口vs抽象类的区别？是否要为每个类定义接口？

Posted 2022-01-03 鮀城小帅

1. 抽象类和接口的语法特性

抽象类不允许被实例化，只能被继承。它可以包含属性和方法。方法既可以包含代码实现，也可以不包含代码实现。不包含代码实现的方法叫作抽象方法。子类继承抽象类，必须实现抽象类中的所有抽象方法。

接口不能包含属性，只能声明方法，方法不能包含代码实现。类实现接口的时候，必须实现接口中声明的所有方法。

2. 抽象类和接口存在的意义

抽象类是对成员变量和方法的抽象，是一种 is-a 关系，是为了解决代码复用问题。接口仅仅是对方法的抽象，是一种 has-a 关系，表示具有某一组行为特性，是为了解决解耦问题，隔离接口和具体的实现，提高代码的扩展性。

3. 抽象类和接口的应用场景区别

什么时候该用抽象类？什么时候该用接口？实际上，判断的标准很简单。如果要表示一种is-a 的关系，并且是为了解决代码复用问题，我们就用抽象类；如果要表示 一种 has-a 关系，并且是为了解决抽象而非代码复用问题，那我们就用接口。

目前项目中controller是基于抽象类实现的，controller 的主要变量和处理逻辑方法都抽取出来，一个是访问参数的解析、封装处理后传给service层用；另一个复用的方法则是走工作流的方法。简单来说就是： 请求 -> 到达controller -> handler方法解析请求参数与值，并封装到对象 entity  -> setFlow方法，填充 entity 以及 activitiName 调用底层process() 方法执行工作流流程。

基于接口的实现就很多了，基本上 service 层就是基于接口实现的。

4. 思考

这里也引出一个问题，如果我在service层需要使用某个全局变量时，是在当前serviceImpl定义还是将接口类改为抽象类，去以 is-a 的方式进行实现？如果单纯只是接口类，却定义了变量是否违反了接口类的 has-a 关系原则？

5. 定义接口的必要性

（1）“基于接口而非实现编程”，这条原则的另一个表述方式，是“基于抽象而非实现编程”。后者的表述方式其实更能体现这条原则的设计初衷。我们在做软件开发的时候，一定要有抽象意识、封装意识、接口意识。越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性、扩展性、可维护性。

（2） 我们在定义接口的时候，一方面，命名要足够通用，不能包含跟具体实现相关的字眼；另一方面，与特定实现有关的方法不要定义在接口中。

（3） “基于接口而非实现编程”这条原则，不仅仅可以指导非常细节的编程开发，还能指导更加上层的架构设计、系统设计等。比如，服务端与客户端之间的“接口”设计、类库的“接口”设计。