程序员修炼之道

月伴飞鱼 2024-08-12 19:08:30
学习书籍 > 编程书籍
支付宝打赏 微信打赏

如果文章对你有帮助,欢迎点击上方按钮打赏作者!

书籍介绍:https://book.douban.com/subject/35006892/

DRY原则

在系统中,对于每一处的知识都要保持单一和明确

书中提到了关于注释不要重复代码实现的想法,其实在接口层加入详细的注释还是有必要的

以较为复杂的查询接口为例,如果不添加详细的注释的话,那么调用者需要深入到接口实现中去找、去看必要了解的知识

  • 如果这个查询接口比较复杂,那么便需要花费比较多的时间

  • 反之,如果有详细的注释,那么便节省了翻看实现的时间

    • 比如说如下查询推荐延保的接口,简略注释只是对方法名的翻译,至于返回值是什么,请求参数需要哪些赋值需要去具体实现中寻找,详细注释则注明了这些内容

程序中最明显的代码重复还是非常值得去处理的,将它们抽象提出来,能够让复用变得更容易

/**
 * 简略注释:查询推荐的延保
 * 详细注释:结果中推荐延保数量至多为 2;入参中分页查询信息 ...
**/
Result queryRecommand(Request req);

为什么书中要反对注释重复方法的实现?

因为它担心修改实现时,忘记维护注释使得注释过时

  • 将注释看成代码的一部分,并约束修改代码时,同时修改注释,是能够避免这个问题的
    • 这样不仅仅是提高可读性,还能提高接口的抽象程度

举例线段类定义:

class Line {
    Point start;
    Point end;
    double length;
}

出现了重复:长度是由起点和终点定义而来的,改变其中之一那么便将引起长度的变化

  • 最好是把长度的定义变成方法
class Line {
    Point start;
    Point end;

    public double length() {
      return end.distanceTo(start);
    }
}

继承税

继承带来的父类与子类之间的 耦合 太深 了,父类中通用字段、方法的变更对子类来说可能带来意想不到的后果

image-20240812191954933

如上继承关系为例:如果最高父类中某些内容发生变更,子类中对其使用的话,那么可能会引起子类行为的改变

而这种改变没有导致编译时异常,可能是没办法发现的,这样使得代码的可维护性大大降低

  • 而且维护在每个类中的知识会在继承关系之间波动,暴露了太多的知识出来,做不到抽象和信息隐藏

使用 接口实现来代替类的继承,保证多态性又不会造成信息的紧耦合

使用 组合代替继承:比如想要香蕉,那么直接将包含香蕉的类注入进来,不再通过继承去获取了

继承能被应用需要具备前提条件:

  • 抽象出来的父类不会或很少再变动
  • 开发者变动的前提是对此有清晰的了解

如果不是这样,在业务代码中引入继承树,那带来的复杂性就太高了

重构

在现实中重构总会面临一些问题:

  • 时间压力:这个需求预计3天能开发完,但是为了优化代码设计和逻辑,需要增加2天时间

    • 增加出的额外时间,可能并不会被接受
  • 改动带来的风险

    • 如何才能保证重构的影响全部在可控的范围内非常值得思考,如果重构会引发Bug,那么开发者会宁愿重构并没有开始

重构该成为日常开发中,需要注意和进行的活动

命名

团队内成员将知识统一才是最好的,并不在于它在英文语境下是否表达准确

可以创建相关的文档或者在 README 中将这些命名规范记录下来

  • 这不光降低了命名难度,而且使得团队内成员能够统一,也方便交流
支付宝打赏 微信打赏

如果文章对你有帮助,欢迎点击上方按钮打赏作者!