第11章主要关注如何重构API，重构API的目标是提高其可用性、可维护性和一致性，同时保持向后兼容性，确保现有用户不受影响。
策略体现：
1. 将查询函数和修改函数分离，如果遇到一个“既有返回值又有副作用”的函数，我就会试着将查询动作从修改动作中分离出来。让函数变得简单。
2. 函数参数化：如果我发现两个函数逻辑非常相似，只有一些字面量值不同，可以将其合并成一个函数，以参数的形式传入不同的值，从而消除重复
3. 移除标记函数，标记参数是那些用于指示函数应执行哪部分逻辑的布尔型或枚举型参数。这类参数通常会使函数逻辑变得复杂且难以理解。重构时，应考虑将包含多个逻辑分支的函数拆分成多个职责单一的函数。
4. 保持对象完整
在设计中，应尽量避免将数据项从对象中拆解出来单独传递。这样做有助于保持数据的完整性和一致性，减少数据不一致的风险。
5. 以查询取代参数
如果函数参数仅用于查询某个对象的状态，并且这个对象在函数内部是可访问的，那么可以考虑将参数替换为对该对象的查询。这样可以减少参数的数量，使函数签名更加简洁。
6. 以参数取代查询
相反地，如果函数内部需要多次查询同一对象以获取不同信息，并且这些信息在函数外部已经可用，那么可以考虑将这些信息作为参数传递给函数，以减少函数内部的查询次数。
7. 移除设值函数
如果某个字段在对象创建后不应被修改，那么就不应该为该字段提供设值函数（setter）。这有助于确保对象的不可变性，从而增加代码的健壮性和安全性。
8. 以工厂函数取代构造函数
在某些情况下，使用工厂函数来创建对象可能比直接使用构造函数更加灵活和方便。工厂函数可以根据需要返回不同类型的对象实例，而无需修改客户端代码。
9. 以命令取代函数
当需要将函数的调用封装成一种可以撤销、重做或记录的操作时，可以考虑将函数替换为命令对象。命令对象封装了操作的所有信息，包括接收者、操作名称和参数等。
10. 识别并重构代码中的“臭味道”
在重构过程中，还需要识别并消除代码中的“臭味道”，如重复代码、过长函数、过长参数列表、神秘命名等。这些“臭味道”通常表明代码中存在潜在的问题或改进空间。