共计 1162 个字符，预计需要花费 3 分钟才能阅读完成。
抽象类和接口的抉择准则
上次的文章讲述了接口的带来的益处之后，我说会持续写一写如何在接口和抽象类之间抉择，因为清明假期以及我最近始终在看 AQS 的实现并且还要上课，所以这篇文章推延了很久，因为明天早上没课，终于狠下心起早床写完这篇。上面就间接进入正题。
其实接口和抽象类的抉择原理还是有点难度的，工作了很多年的老码农也不敢说肯定可能了解，因为波及到面向对象，要可能正确理解接口和抽象类的抉择势必要可能了解面向对象，我很早就说了面向对象不是一种技术而是一种思维，是一种编码的形式，大家不要误会面向对象，总这么说显得有点空洞，我将举一个例子来帮忙大家了解，这个例子也是我在 csdn 上看到的，我感觉写的很好，也很有代表性。
假如咱们在一家车企工作，你在公司的技术部门，公司必定有销售部门，销售车时必定是要展现一些参数突出车子的长处的。假如销售部门提出一个需要，要求展现车子的能源参数，于是你屁颠屁颠的开始写代码。你可能写了一个形象 Motor 类，如下：
因为科技还没有很发达，还在应用燃油发动机，于是你写了一个燃油发动机类去继承 Motor，而后交付了 1.0 版本的 APP，应用的很晦涩，你暗暗自喜，感觉本人的代码优雅的像诗一样。
随着工夫的推移，科技进步了，呈现了光发动机和电发动机，因为电池充电速度是用户很在意的一个参数，而光的强度太弱时光发动机又不能工作，于是返回以后环境的光强也是一个很重要的参数，于是你又别离写了对应的类，同样去继承 Motor，退出了获取光强和充电工夫的代码，如下：
仍然是高枕无忧，完满应用无 bug。就在这个时候车企造出了光电混合发动机，仍然叫你展现车的能源参数，然而这个时候你懵了，光电混合发动机这个类到底应该继承哪个基类呢。
很显然光电发动机不能继承 Motor，这样做会导致应用 instanceOf 操作符时失去的后果是该发动机既不属于光发动机也不属于电发动机，然而很显然，事实的状况是光电发动机应该应该同时属于光发动机和电发动机。接着你又想让光电混合发动机继承光发动机和电发动机中的任何一个 (因为 JAVA 不容许应用多重继承，所以只能继承一个)，然而这样做之后在应用 instanceOf 操作符时失去的后果是光电混合发动机只属于光发动机或者电发动机，这个后果显然也是不够正当的，于是你解体了，你不得不重构代码，于是你将代码的继承构造改成了如下构造
电发动机
光发动机
当初光电混合发动机就很好形容了
多重实现光发动机接口和电发动机接口就完事了，于是交付软件，这个 APP 又能够失常跑了，你真是太棒了。
通过这个例子繁难的形容了接口和抽象类到底应该怎么抉择，在设计一个类的时候，如果要将该类设计成为基类，则思考该类中有没有属性或者成员办法，如果没有就设计成一个接口，如果有就设计成一个抽象类，如果切实不分明如何抉择，那么则间接设计成接口。
