接⼝和抽象类使⽤场景
接⼝和抽象类的使⽤动机不同，从⽽决定是使⽤接⼝还是使⽤抽象类，使⽤抽象类是为了代码的复⽤，使⽤接⼝是为了实现多态，当不确定使⽤接⼝还是使⽤抽象类时，就从使⽤⽬的出发决定，提⾼代码复⽤性就是⽤抽象类，想实现多态就是⽤接⼝。
使⽤抽象类的场景
1. 抽离重复代码
2. 实现多态
使⽤接⼝类的场景
1. 实现类可以扩展功能，也可以选择不扩展功能
2. 是规范⼊参和出参类型
3. 实现多态
如果某些类都可以有功能⽅法或属性，那就把这些功能⽅法封装为抽象类。
如果某些类满⾜场景的变化，各个类可选择添加功能⽅法或不添加功能⽅法，那就把这些功能⽅法封装为接⼝。
使⽤抽象类还是接⼝：
1. 如果要设计的⽅法是场景中某个类型“与⽣俱来、⼀脉相承”的（⽆论以后场景如何变化，该⽅法都肯定会存在于类型当中），那么
这样的抽象⽅法就应该设计到“抽象类”当中。
2. 如果要设计的⽅法并不是场景中某个类型的根本，⽽是为了满⾜场景变化的丰富度选择性添加或不添加的，那么这样的抽象⽅法就应
该设计到“接⼝”当中。
3. 设计“接⼝”的时候，请注意⚠ 要满⾜“接⼝隔离原则”。不要把可能会分离的⽅法放到⼀个⼤接⼝当中了，这样的话会造成让实
现类拥有了不该有的⽅法（我们把这种情况叫做：接⼝污染）。
接⼝和抽象类是为业务场景服务的。
有这么⼀个场景，要设计⽣物的特性。
⾸先我们要搞清楚，⽣物有哪些，特性有哪些。
⽣物有：狗，猫，猪，⼩麦，⼤⾖。
特性有：吃，呼吸，懒惰，看门。
把这些特性针对与⽣物进⾏抽离，共同点封装为抽象类，异同点封装为接⼝。
显然呼吸的特性是这些⽣物共有的，呼吸的⽅法实现逻辑都可以满⾜⽣物呼吸的需求，这时就没有必要封装接⼝，让各个⽣物重写呼吸⽅法逻辑，这样反⽽增加冗余代码。
那我们就可以把呼吸⽅法逻辑封装为⽣存抽象类。提供默认呼吸实现，⽣物共享呼吸的⽅法逻辑。
如果要实现吃饭的功能，应该封装为吃饭接⼝，让狗，猫，猪实现各⾃的吃饭⽅法逻辑，⽽⼩麦，⼤⾖不需要实现吃饭接⼝。
如果⽣物只有狗，猫，猪，并且都是⽤嘴实现吃饭，那么吃饭⽅法就可以封装为吃饭抽象类。
如果为⽣物添加懒惰的⾏为，⾸先懒惰⾏为并不是⽣物⼀定要有的，所以这⾥把懒惰封装为懒惰接⼝，
让猪去实现，狗和猫选择性是否要实现。
同理看门也不是这些⽣物的共同功能，所以也应该封装为看门接⼝。
抽象类的使用
因此我们在设计代码，使⽤接⼝还是抽象类时。
前提要确定两点：⼀是需要为哪些类提供接⼝或抽象，⼆是这些类的特性有哪些。
从⽽抽离共同逻辑代码封装为抽象类。
差异点封装为接⼝⽅法，让各⾃的类去重写这些差异功能。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。