7.1 Rename method (函数改名)
极力推荐的一种编程风格就是： 将复杂的处理过程分解为小函数。但是，如果做的不好，会费尽周折却弄不清楚这些小函数各自的用途。要避免这种麻烦，关键就在于 给函数起一个好名字。函数的名称应该准确表达它的用途。
7.2 Add Parameter (添加参数)
当某个函数需要从调用端得到更多信息，可以为函数添加一个对象参数，让该对象带进函数所需信息。但是这样做经常会走向另一个极端，导致参数太多。所以每增加一个参数都要慎重。或许也可以考虑使用Introduce Parameter Object.
7.3 Remove Parameter (移除参数)
如果函数本体不再需要某个参数，果断将该参数去除。
7.4 Separate Query form Modifier (将查询函数和修改函数分离)
某个函数既返回对象状态值，又修改对象状态。这时可以建立两个不同的函数， 其中一个负责查询，另一个负责修改。这条准则并不是说一个函数如果修改了对象状态就不能有返回值，而是如果返回值是要经过一系列查询比较等操作获得的，就需要把这一系列动作封装为一个独立的查询函数，使得查询函数和修改函数逻辑独立分开，但是可以嵌套调用。 有一个设计原则就叫：命令查询分离。
7.5 Preserve Whole Object (保持对象完整)
如果从某个对象中取出若干值，将它们作为某一次函数调用时的参数，则可以改为传递整个对象。一个好处是可以减少参数个数，另一个还可以预防以后又需要从这个对象获取其他值。
不过事情总有两面，如果你传的值是数值，而被调用函数就只依赖于这些数值，依赖关系比较稳定，那就坚决不要传递整个对象。
但是如果一个函数依赖另一个对象过多数据时，就要考虑是否Feature Envy，需要把这个函数移到适合它的地方了。
7.6 Introduce Parameter Object (引入参数对象)
如果某些参数总是很自然地同时出现，则以一个对象取代这些参数。
常会看到 特定的一组参数总是一起被传递。可能好几个函数都使用这一组参数，这些函数可能隶属同一个类，也可能不隶属同一个类。 这样一组参数就是所谓的Data Clumps(数据泥团)，我们可以运用一个对象包装所有这些数据，再以该对象取代他们。
7.7 Replace Constructor with Factory Method(以工厂函数取代构造函数)
《effective java》开头也提出了这个准则，可以隐藏构造方法，更清晰、安全的以工厂方法来代为构建对象。
7.8 Repalce Error Code with Exception (以异常取代错误码)
某个函数返回一个指定的代码，用以表示某种错误情况。可以改为异常的形式返回。
程序发生错误时，并不一定知道如何处理错误。所以必须要让调用者知道错误，调用者可能可以解决也可能需要继续向上传递。Java的异常是非常好的报告错误的方式。我们可以根据错误是否可以被修复决定使用受检查异常还是非受检查异常。
但是一定要杜绝异常滥用，异常只用来表示异常的情况，有些校验不通过属于正常的情况，就不需要抛出异常了。