Daniel Hu的技术生活博客

这两天review同学的代码，除了代码本身的质量（注释、命名、函数过长等等)以外，还能感觉到代码中那种heavy（沉重）的感觉，于是用借着这篇博文把这些感觉整理出来。

要索取资源而不是自己去寻找资源（也就是依赖注入和笛米特法）。

例如我们的代码有一个文件的下载器要实现，文件下载器除了要处理要知道一个下载文件的源路径以外，要需要两个参数，其中一个是下载完成以后将文件保存到的目录，还有一个是下载失败的重试次数。在同学的实现中是由下载器这个类实现这两个参数的获取逻辑。代码看到这里就就让我对文件下载器的实现有一种沉重的感觉，这种感觉就是这两个参数的获取逻辑对整个文件下载器可重用性的破坏。这种实现就会导致整个文件文件下载器只能将文件输出到某个特定的目录，导致这个文件下载器对这个特定配置（不管配置数据是保存数据库中还是配置文件）的依赖，也就是说下次要重用这个文件下载器（例如文件下载器的使用场景发生变化，或是有新的场景要对文件进行下载）还必需要提供给这配置项保存的资源，如果是配置项是保存到数据库中的，就必须要移植相应的表结构和DAO访问层。这种实现会让当前文件下载器被重用的几率只有“零”。所以在文件下载器的设计上要贯彻“索取资源而不是自己去寻找资源（也就是依赖注入和笛米特法）的原则”，也就是让文件下载器的消费者在构造文件下载器的时候提供文件下载器所需依赖的参数，这样让文件下载器具备100%的可重用性。至于说文件下载器的调用方本身就是负责某个具体业务的实现，本身的重用需求就比较小，依赖特定的上下文也是合理的。