软件框架-无绪开发3

编程：面向接口而非实现 

从实现中分离接口，再作为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中不支持数据写