《重构》读书笔记11（第十一章完结）

第11章 重构API

11.1将查询函数和修改函数分离

必须得分离，不然每次查询都会造成修改，很有可能会产生副作用。要么查询要么修改，一次只做一件事，不要混在一块做，把原来的函数拆成两个责任明确的函数。

11.2函数参数化

同样的逻辑下只是有些数值的区别，可以提炼出函数，把这些数值作为参数传入，就避免了重复代码。

11.3移除标记参数

写oj题目的时候挺常用的，用个flag来区分不同的逻辑处理，但在代码量大的时候挺乱的，一眼看不出来有什么区别是要干嘛，最好把不同情况对应的处理逻辑提炼，并看下能不能把flag判断上移至调用者，有时候甚至会发现上移后根本不需要这个flag判断了。

11.4保持对象完整

从一个记录里导出一些值作为参数传给函数的时候可以考虑直接传完整记录给函数，万一以后函数需要别的值就不需要改变接口，直接在函数里修改逻辑就好。

11.5以查询取代参数&11.6以参数取代查询

互为逆重构。
前者推迟查询到函数内而不是调用处传参进去；后者则是将函数内的查询和函数本身解耦，这俩要权衡看用哪个在当前更合适。

11.7移除设值函数

不需要更改某个字段的话，就应该声明为不可修改并去掉设置函数，把设值提前到构造函数里，这样可以避免被修改。

11.8以工厂函数取代构造函数

在构造函数的调用处，如果希望根据环境或者参数返回不同的实例，就应该用工厂函数，在函数中根据情况来返回不同的实例。

11.9以命令取代函数&11.10以函数取代命令

最近刚好在游戏设计模式里看到命令模式，就是以命令取代函数，当操作逻辑比较复杂时可以构造命令类+类内执行函数的模式，这样代码更清楚可读，还能提供撤销操作。
但当命令的逻辑并不复杂的时候，就可以考虑改成函数实现。

-FIN-