常见的代码坏味道--多层嵌套，缺乏封装

1. 多层嵌套

多层嵌套的两个原因

1.1 if else

最简单的重构手法，提前 return ,也叫 Replace Nested Conditional with Guard Clauses 卫语句。

有一些比较激进的看法认为 else 本身就是一种坏味道。

可以使用 idea 的插件 Checkstyle 检查一下代码的 圈复杂度。当圈复杂度大于某个值的时候，就会报错。

圈复杂度的这部分代码中线性无关路径的数量。

如果一段源码中不包含控制流语句（条件或决策点），那么这段代码的圈复杂度为1，因为这段代码中只会有一条路径；如果一段代码中仅包含一个if语句，且if语句仅有一个条件，那么这段代码的圈复杂度为2；包含两个嵌套的if语句，或是一个if语句有两个条件的代码块的圈复杂度为3。

第二种解决过多判断的方案是多态，这就要求从设计阶段就开始考虑实现方案。

注意多态的本质是想要实现对拓展开发，对修改关闭，所以如果继承的层级较多，逻辑比较复杂，就会导致适得其反的效果。

1.2 for 循环

对集合进行循环操作推荐使用java8的Stream操作（,mapreduce，map代表操作，collect代表reduce），比如。从本质上讲Stream也是循环，但是这种语法糖的形式会对各种操作进行分类，进行合理的优化处理。

循环和函数式编程的区别不仅仅在写法上，更体现在思想上。前者描述实现细节，后者描述做什么。

当然，如果在列表转换中使用过多的 lambda 表达式，会导致看起来很吃力，不好理解。这时候长的lambda本身可以提取成为方法。

2. 缺乏封装

2.1. 过长的消息链或者说火车残骸

第一种缺乏封装的表现是java类处理不当，可能是设计的太粗糙，面向过程实现业务逻辑导致的。这就要求开发的时候进行更多的抽象。比如，不是所有的java类都直接提供所有的getter setter 方法就行，还要根据业务场景进行合理选择；另外对象内部的细节不需要过多的暴露出去，应该做适当的封装。

2.2 基本类型的偏执

第二种更高级的缺乏封装，是指用基本类型代表所有的业务数据。比如

这是获取价格的方法，返回一个 double 代表价格。 就算 double 可以保证计算精度，这里也还可以进一步优化，比如，经常要求商品价格是大于0的，所以会有下面的逻辑

这就是因为 double 作为基本类型并没有 价格大于0 的方法。 

这里的解决办法，就是 Replace Primitive with Object ，以对象取代基本类型。

 甚至有人认为需要封装所有的基本类型和字符串，并且使用一流的集合。