A Philosophy of Software Design读书笔记——复杂度下移

本章讲解如何创建一个深的模块。

当要新建一个新的模块时，有两种方式：1、要模块用户处理复杂度；2、模块内部处理复杂度。如果复杂度关系到模块内部的功能，则第二种方式更好，即要将复杂度下移

配置参数

配置参数有时会增加复杂度，将参数暴露给使用者，让使用者决定模块的行为，比如缓存大小、重试次数。这种行为在当前软件开发中很流行。

某些情况下，使用者更好的知道采用模块中的那种行为更合适，开发者很难决定模块的行为，比如：某些请求的超时时间设置。

但是某些情况下，使用者不需要知道或者很难知道参数，比如网络中的丢包处理。

在使用配置参数之前，要搞清楚：是否一定要用户决定模块的行为，一些默认行为是否合理，如果实在无法避免，可以给配置参数类创建一个默认的构造函数，代表模块的默认行为，这样用户只需要解决特殊情况。

理想情况下，不需要提供配置参数，配置参数意味着复杂度处理不彻底。

再说几句

用默认行为可以降低复杂度，极端方式把所有功能集中到一个类中，这显然是不合理的，合理的降低复杂度方式：1、这个类就是实现这个功能的，那么抽象出这个类是合理的；2、在某个模块处理了复杂度之后，其他模块变得简单了；3、在实现的功能不变的情况下，接口变得简单

我们最终的目标是降低全局的复杂度，而不是某个模块的复杂度

总结

开发模块时，可以站在使用者的角度去看，而不是站在开发者的角度。