《软件设计重构》读书笔记（3）-封装型缺陷

封装原则倡导通过隐藏实现细节和封装变化还实现关注点分离。违反了封装原则会导致封装性缺陷。下图展示了封装原则的实现方法和相对应的封装型缺陷。

下面详细说明这四种封装型缺陷。

不充分的封装 缺陷

【概念定义】对于抽象的成员，声明的访问权限超过了实际需要的权限，会导致不充分的封装缺陷

【违反原则】违反了封装原则，依赖倒转原则

【缺陷实例】类中声明的公有字段，如System.in和System.out；极端情况是存在一些全局的变量和数据结构（public static）。

【重构建议】将类中的字段修改成私有的，并提供共有的访问器方法。这样客户的程序只依赖于接口，而不依赖于具体的实现。

泄漏的封装 缺陷

【概念定义】抽象通过公有接口暴露了底层的实现细节，会导致以后的修改升级变得困难，同时使得客户程序直接可以修改内部状态。导致了泄漏的封装缺陷。

【违反原则】封装原则

【缺陷实例】对于某应用，用于存放待排序对象的ArrayList底层数据结构,提供公有方法getList()直接返回底层的list，使客户可以直接修改该array list。

【重构建议】不要向客户放回内部数据结构的指针。可以考虑返回内部数据结构的深层克隆或者一个不可修改的对象。对上例而言，在公有方法getList()中，对底层的list进行复制，生成一个新的ArrayList并作为方法的返回值返回给用户。

【实现考虑】对于提供给客户的访问器方法，要仔细考虑，那些底层字段可以直接返回给客户，那些字段需要进行包装处理。

缺失的封装 缺陷

【概念定义】没有将实现变化封装在抽象或层次结构中，导致每次修改既存子类或增加新子类时，都会影响客户程序，或添加大量的新类。

【违反原则】开闭原则（OCP）

【缺陷实例】对于某加密处理工具，在抽象类中对每种加密算法都定义一个公用接口。如果要增加一种算法，都需要增加一个方法与之对应。见下图

【重构建议】使用策略模式，将不同的算法单独抽象出来，并作为工具类的一个成员。见下图。

未利用的封装 缺陷

【概念定义】客户代码使用显式的类型检查代码（if/else或switch）,而不是利用层次内已经封装好的类型多态性，将导致这种缺陷。

【违反原则】封装原则

【缺陷实例】java.awt.ColorModel类中，使用switch语句检查数组 的显式类型，从而针对不同类型的数组进行基本类似的操作。

【重构建议】使用抽象手法将不同类型的数组抽象为不同的类，在程序中利用多态性进行处理。

【实现考虑】在实例化ColorModel类时，需要根据不同的类型码在构造函数中指定不同的抽象类。这样，在客户端构造代码时需要判断语句，但是在代码库中就不用充斥各种switch-case判断语句。