《Clean Code》学习之-Functions

        这一章Bob大叔把我们带入了函数的世界。在这一章中，大叔也提出了不少新颖的观点，并且一直强调的一件事就是—do one thing。这是Bob大叔关于函数的思想的核心。下面来看看这一章主要都讲了些什么。

       1.Small（短小精悍）

        The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.（函数的第一原则是精简，第二条原则是更精简）

        In the eighties we used say that a function should be no bigger than a screen-full. Today Lines should not be 150 characters on a line and 100 lines or more on a screeen. Functions should hardly ever be 20 lines long.

        2.Blocks and Indenting

        在if表达式以及else表达式或者while表达式中的块应该提炼成函数。

       3.Do One Thing（只做一件事）

        Functions should do one thing. They should do it well. They should do it only.

        4.One Level of Abstraction per Function

        In order to make sure our functions are doing “one thing”, we need to make sure that the statements within our function are all at the same level of abstraction.

        Mixing levels of abstraction within a function is always confusing.

        5.Reading Code from Top to Bottom: The Stepdown Rule

       6.Switch Statements

        Payroll.java

        public Money calculatePay(Employee e)

        throws InvalidEmployeeType{

            switch (e.Type){

                  case COMMISSIONED:

                       return calculateCommissionedPay(e);

                  case HOURLY:

                      return calculateHourlyPay(e);

                  case SALARIED:

                       return calculateSalariedPay(e);

                   default:

                        throw new InvalidEmployeeType(e.Type);

            }

      }

        上面的代码存在的问题：

        （1）首先，函数比较大，并且增加新的雇员类型时，函数的长度会增加；

        （2）很明显，该函数做了不止一件事；

        （3）违背了单一职责原则；

        （4）违背了开放封闭原则，因为只要有新的类型加入，这个函数就要改变；

        （5）最糟糕的可能是这个函数会引入没完没了的就有相同结构的其它方法。

        解决上面的方法是采用抽象工厂模式（Abstract Factory）。

      7.Use Descriptive Names（使用描述性的命名）

        The smaller and more focused a function is, the easier it is to choose a descriptive name.

        Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a descriptive comment.

        Choosing descriptive names will clarify the design of the module in your mind and help you to improve it.

        8.Function Arguments（参数）

        函数没有参数最好，一个或者两个参数尚能接受，三个应该尽量避免，多于三个基本上不应该用了。

        输出参数比输入参数更难于理解，阅读函数的时候，我们习惯通过参数获取输入信息，通过返回值获取输出信息，而不是通过参数来获取输出信息。

        9.Common Monadic Forms（单一参数形式）

        在函数中使用一个参数通常有两个理由：（1）你可能要针对这个参数提出一个问题，如boolean fileExists(“MyFile”)；（2）你可能对参数进行处理--将它转换成其它形式并返回，如InputStream fileOpen(“MyFile”)。

        单一参数函数的一种稍微少见但非常有用的形式是事件。

        使用返回值参数而不是返回值会让人觉得迷惑。

        10.Flag Arguments

        布尔参数让人很讨厌。如果一个函数使用了状态参数，这表明这个函数做的事情超过了一件。

        11.Dyadic Functions（带有两个参数的函数）

        带有两个参数的函数比带有一个参数的函数更难于理解，但有时候两个参数也比较合适。具备三个参数的函数远比两个参数的函数要难懂。（这段作者写得比较啰嗦，可以看看原文）

        12.Argument Objects（对象参数）

        当一个函数使用三个以上的参数时，可以考虑将其中的一些参数包装成一个对象。

        13.Arguments List（参数列表）

        14.Have No Side Effects（没有副作用）

        函数不能有副作用，指的是函数不能做它的名字所没有描述的事情，树上的例子Listing 3-6中存在的问题是函数名为checkPassword，但是在里面对Session做了Initialize操作，这样其它人在调用的时候很容易忽略掉里面的初始化操作。

        15.Command Query Separation（查询与命令分离）

        函数要么做某件事，要么回答某个问题，而不要两者都做。

        16.Prefer Exceptions to Returning Error Code

        17.Extract Try/Catch Blocks（将try/Catch块提取成函数）

 

 

        感觉将英文中的内容用中文表达出来还是挺别扭的，难怪很多人翻译外国人的书都翻译得怪怪的。希望没有断章取义。