编程:面向接口而非实现
从实现中分离接口,再作为API提供出去
牢记: 不要去依赖那些没有在文档中提起的属性和资源
应该向设计者要求提供合适的API
抽象定义和实现内容要分离
1.移除方法或者字段
public 类型,最好不移除,否则用户的代码可以不兼容了
private类型,可以移除
protected类型,也许可以移除,但也可能出现问题
2.移除或者添加一个类或者接口
一旦公布,就像恒星,必须存在下去。
3.向现有的继承体系中添加一个类或者接口
特定环境,可以带来好处
4.添加方法或者字段
static方法可行,但只能写到类中
避免添加新的抽象方法:抽象方法不能向后兼容
添加具体方法:意外干扰是最大问题
5.接口和类的区别
C++ 中接口是纯虚函数组成的类
对性能的追求是唯一实现的理由
多继承可以减少对内存的占用,利用多继承仅使用一个对象就可实现API中公开的多个接口
6. 弱点背后的优点
接口:添加方法向后兼容几乎不可能,因为客户端可能会特别冗余;但也是优点,功能固定,代码清晰
希望:拓展功能时,明确指出一个不会改变的接口
7.添加方法的另一种方案
不可被继承的类,唯一可能出现兼容问题是在调用类的方法时。
避免方法: 不要加入具有相同数量参数的同名方法。
8.抽象类
一般来说,可接受
9.要为增加参数做好准备
(1) 需要增加一个新的方法来调用先前的那个方法
给用户一个类去实现,不如给他一个接口来实现
(2)考虑API改进,解决方案是Request/Response模式(参数有输入信息,有返回信息)
Request: 只将 getter 方法公开(公有public),其他方法只对友元类开放(私有private) 【不可继承类】
Response: 只将setter方法公开(公有public),其他方法只对友元类开放(私有private)【不可继承类】
这两个都是类,以后只需增加新的Request方法即可
记住:在对方法进行改进时,方法的参数也应该可以无风险的进行改进
在Request中不支持数据读;在Response中不支持数据写