接口和抽象类使用场景

接口和抽象类的使用动机不同，从而决定是使用接口还是使用抽象类，使用抽象类是为了代码的复用，使用接口是为了实现多态，当不确定使用接口还是使用抽象类时，就从使用目的出发决定，提高代码复用性就是用抽象类，想实现多态就是用接口。

使用抽象类的场景

1. 抽离重复代码
2. 实现多态
   使用接口类的场景
3. 实现类可以扩展功能，也可以选择不扩展功能
4. 是规范入参和出参类型
5. 实现多态

如果某些类都可以有功能方法或属性，那就把这些功能方法封装为抽象类。
如果某些类满足场景的变化，各个类可选择添加功能方法或不添加功能方法，那就把这些功能方法封装为接口。

使用抽象类还是接口：

如果要设计的方法是场景中某个类型“与生俱来、一脉相承”的（无论以后场景如何变化，该方法都肯定会存在于类型当中），那么这样的抽象方法就应该设计到“抽象类”当中。
如果要设计的方法并不是场景中某个类型的根本，而是为了满足场景变化的丰富度选择性添加或不添加的，那么这样的抽象方法就应该设计到“接口”当中。
设计“接口”的时候，请注意⚠️要满足“接口隔离原则”。不要把可能会分离的方法放到一个大接口当中了，这样的话会造成让实现类拥有了不该有的方法（我们把这种情况叫做：接口污染）。
接口和抽象类是为业务场景服务的。
有这么一个场景，要设计生物的特性。
首先我们要搞清楚，生物有哪些，特性有哪些。
生物有：狗，猫，猪，小麦，大豆。
特性有：吃，呼吸，懒惰，看门。
把这些特性针对与生物进行抽离，共同点封装为抽象类，异同点封装为接口。
显然呼吸的特性是这些生物共有的，呼吸的方法实现逻辑都可以满足生物呼吸的需求，这时就没有必要封装接口，让各个生物重写呼吸方法逻辑，这样反而增加冗余代码。
那我们就可以把呼吸方法逻辑封装为生存抽象类。提供默认呼吸实现，生物共享呼吸的方法逻辑。

如果要实现吃饭的功能，应该封装为吃饭接口，让狗，猫，猪实现各自的吃饭方法逻辑，而小麦，大豆不需要实现吃饭接口。
如果生物只有狗，猫，猪，并且都是用嘴实现吃饭，那么吃饭方法就可以封装为吃饭抽象类。

如果为生物添加懒惰的行为，首先懒惰行为并不是生物一定要有的，所以这里把懒惰封装为懒惰接口，让猪去实现，狗和猫选择性是否要实现。
同理看门也不是这些生物的共同功能，所以也应该封装为看门接口。

因此我们在设计代码，使用接口还是抽象类时。
前提要确定两点：一是需要为哪些类提供接口或抽象，二是这些类的特性有哪些。
从而抽离共同逻辑代码封装为抽象类。
差异点封装为接口方法，让各自的类去重写这些差异功能。