• (读书笔记)


    1. 移除重复代码
    2. 将注释转换为代码

        什么样的类是看代码的人最喜欢的?那就是简单易看的类.一个设计得好的类,能够让人家一眼就能出你这个都有些什么东西,明白你这个类都做了一些什么事.如果看这个类的时候,要不停的将屏幕滚来滚去,而思维还要屏幕的滚动跳转,无形中,看懂这个类需要花的时间就多了.

    • 将注释转换为代码,让代码足够清楚到可以表示注释
    • 将注释转换为变量名
    • 对参数的注释转换为参数名
    • 将注释转换为方法的一部分
    • 删掉没有用的注释
    • 将一部分重复代码重构成方法,用方法名来表示代码的注释
    • 用注释去命名一个已经存在的方法
    • 同时要避免方法名过长。

    为什么要删除额外的注释?其实,加注释本身是一个很正确的事情,因为注释可以让人更容易的理解代码.因为序员觉得光光代码,可能还不能让人完全理解.

    而问题就在于,因为常常没有把代码写清楚,所以我们就找了一个捷径,那就是写上注释.注释不够清楚,再写档.好,这样子,程序可以让人看得懂了吧.

    而这样造成的结果就是,没有人愿意去好好的组织代码,让代码清楚起来,因为他们觉得加上注释就好了.

    之后,代码更新了,可是程序员却常常忘了去更新注释(我们不得不承认,这种情况经常发生,这点,再好的软件都会有这种问题的存在).

    过了一段时间,这些过时的注释不仅不能让代码更容易懂,反而会误导了读代码的人.

    到了最后,我们剩下的东西就是:本身就不清晰的代码,混上一些不正确的注释。

    因此,不管任何时候,当我们要加注释的时候,我们应该再三的想想:

               我的注释能不能转化在代码里面,让代码跟注释一样的清晰? 
    而大多数情况下,我们得到的答案都是:能!
     每一个注释都是一个改进代码的好机会!
    我们不能说,注释少的代码就是好代码.
    但我们绝对可以说,包含太多注释的代码,绝对不是高质量的代码.
    1. 移除代码异味

       要判断代码的稳定性,我们可能会这样来判定:先假设一些具体的情况或者需求变动了,然后来看一看,要满足这些新的需求,代码是否需要被修改?  
      可惜,这也是一件很麻烦的事,因为有那么多的可能性!我们怎么知道哪个可能性要考虑,哪些不用考虑?

      有个更简单的方法,如果发现说,我们已经第三次修改这些代码了,那我们就认定这些代码是不稳定的。这样的方法很“懒惰”,而且“被动”!因为这是在我们被伤到了以后,才开始处理问题。虽然这种方法还算一个很有效的方法。
      此外,还有一个简单,而且“主动”的方法:如果这段代码是不稳定或者有一些潜在问题的,那么代码往往包含一些明显的痕迹。正如食物要腐坏之前,经常会发出一些异味一样(当然,食物如果有异味了,再怎么处我们都不想吃了。但是代码可不行。)。我们管这些痕迹叫做“代码异味”。并不是所有的食物有异味都不能吃,但大多数情况下,确实是不能吃了。并不是所有的代码异味都是坏事,但大多数情况下,它们确实是坏事情!

      因此,当我们感觉出有代码异味时,我们必须小心谨慎的检查了。

    • 代码用了类别代码(type code)

            想要去掉一个类别代码有2中方法:一是为每一种类建立一个子类,二是用一个对象代替一个类别。

    • 方法中还有Switch或是一大堆的if else if。Switch表达式一般是跟类别代码一起出现的。

          用抽象类或接口通过继承来描述不同的类别以消除Switch或是一大堆的if else if。将不同的类别共同的方法放到父类或接口中,在子类中通过继承去表述不同的意义。

      总结一下类别代码的移除

        要移除一些类别代码和Switch表达式有2种方法:

          1、用基于同一父类的不同子类来代替不同的类别。

          2、用一个类的不同对象来代替不同的类别。

            当不同的类别具有比较多的不同的行为的时候,用第一种方法。当这些类别的行为非常相似,或者只是差别在一些值上面的时候,用第二种方法。

    • 一个类有很多属性有时候是不用的
    • 想给变量一个好一点的名字都做不到,因为为不同情况下他们有不同的含义
    • 太多的注释
    • 方法或类的代码太多或者说太长
    • 方法的参数过多
    • 2个类彼此引用(依赖于彼此)
    1. 保持代码简洁

    要判断一个类是否需要修整,一个比较主观的方法是:当在读一个类的代码时,看看我们会不会觉得这个类“太长了”,“太复杂了”,或者讲的概念“太多了”?如果会这样觉得的话,我们就认定,这个类需要修整。

    另外一个比较简单而且客观的方法是:当发现我们已经在第二次或者第三次扩充这个类的时候,我们认定这个类要修整了。这是一个比较”懒惰,被动”的方法,但却很有效。

    单一职责原则(The Single Responsibility Principle)认为:每个类都应该只为一个理由而修改。当一个类包含许多其他的功能时,很明显违反了单一职责原则。

    1. 慎用继承
    • 继承了一些不合适(或者没有用)的功能

         当我们继承了一些我们不想要的东西,我们应该再三的想想:他们之间是不是真的有继承的关系?弄清楚父类和子类需要表述的逻辑关系,理清思路。

            代理(delegation)

           当一个类只是作为一个中间介让外界调用另外一个类中的方法,我们管这样传递调用的中间介叫代理。

            用“代理”的优点就是我们可以通过修饰符(public)去控制类中的方法哪些可以“公布”,如果用继承的话就没得选择了。内部可见和外部可见的问题。

    • 如果一个父类所描述的东西不是所有的子类所共有的,那这个父类的设计肯定不是一个好的设计。
    1. 处理不合适的依赖

         怎么判断是“不合适的依赖”:

            方法一:有没有一些互相循环的引用。具有局限性,并不是所有的“不合适的依赖”的代码都是这种互相依赖。看代码:有没有相互依赖。

            方法二:在检查代码的时候我们问自己:对于它已经引用的这些类,是它真正需要引用的吗?认真想想:它真的需要什么。

            方法三:在设计类的时候,我们先预测一个以后可能会重用到这个类的系统,然后在那样的系统中去判断,之前的那个类能不能在这里重用?如果你自己都觉得以后的系统不能重用这个类的话,就可以断定这个类包含了“不合适的依赖”。推测一下:它在以后的系统中可以重用吗?

            方法四:当我们在一个系统中重用某个类的时候,却发现重用不了,我们就判断该类包含了“不合适的依赖”。到重用的时候就知道了:现在我要重用这个类,能不能重用呢?

    依赖反转原则(Dependency  Inversion  Principle )表述:抽象不应该依赖于具体,高层的比较抽象的类不应该依赖于低层的比较具体的类。当这种问题出现的时候,我们应该抽取出更抽象的一个概念,然后让这两个类依赖于这个抽取出来的概念。

    1. 将数据库访问、UI和逻辑分离
  • 相关阅读:
    图匹配板子
    线性基
    Berlekamp-Massey algorithm
    组合/概率/形式幂级数/多项式/集合幂级数的题
    费用流 Dijkstra 原始对偶方法(primal-dual method)
    UVA-12304
    二项式系数
    卡特兰数
    多项式模板
    工具
  • 原文地址:https://www.cnblogs.com/bluesky4485/p/read.html
Copyright © 2020-2023  润新知