Refactoring之——代码的坏味道（二）过大的类 &（三）基本类型偏执

1.1.2 Large Class（过大的类）

特征：一个类包含过多的字段、方法、代码行。

问题原因：

类通常一开始很小，但是随着程序的增长而逐渐膨胀。

类似于过长方法，程序员通常觉得在一个现存类中添加新特性比创建一个新的类要容易。

解决方法：

设计模式中有一条重要原则：职责单一原则。一个类应该只赋予它一个职责。如果它所承担的职责太多，就该考虑为它减减负。



如果过大类中的部分行为可以提炼到一个独立的组件中，可以使用

提炼类(Extract Class)

。

如果过大类中的部分行为可以用不同方式实现或使用于特殊场景，可以使用

提炼子类(Extract Subclass)

。

如果有必要为客户端提供一组操作和行为，可以使用

提炼接口(Extract Interface)

。

如果你的过大类是个GUI类，可能需要把数据和行为移到一个独立的领域对象去。你可能需要两边各保留一些重复数据，并保持两边同步。

复制被监视数据(Duplicate Observed Data)

可以告诉你怎么做。

收获：

重构过大的类可以使程序员不必记住一个类中大量的属性。

在大多数情况下，分割过大的类可以避免代码和功能的重复。



1.1.3 Primitive Obsession（基本类型偏执）

特征：

使用基本类型而不是小对象来实现简单任务（例如货币、范围、电话号码字符串等）。

使用常量编码信息（例如一个用于引用管理员权限的常量

USER_ADMIN_ROLE = 1

）。

使用字符串常量作为字段名在数组中使用。

问题原因：

类似其他大部分坏味道，基本类型偏执诞生于类初建的时候。一开始，可能只是不多的字段，随着表示的特性越来越多，基本数据类型字段也越来越多。

基本类型常常被用于表示模型的类型。你有一组数字或字符串用来表示某个实体。

还有一个场景：在模拟场景，大量的字符串常量被用于数组的索引。

解决办法：

大多数编程语言都支持基本数据类型和结构类型（类、结构体等）。结构类型允许程序员将基本数据类型组织起来，以代表某一事物的模型。

基本数据类型可以看成是机构类型的积木块。当基本数据类型数量成规模后，将它们有组织地结合起来，可以更方便的管理这些数据。

　　　　　　　　


如果你有大量的基本数据类型字段，就有可能将其中部分存在逻辑联系的字段组织起来，形成一个类。更进一步的是，将与这些数据有关联的方法也一并移入类中。为了实现这个目标，可以尝试

以类取代类型码(Replace Type Code with Class)

。

如果基本数据类型字段的值是用于方法的参数，可以使用

引入参数对象(Introduce Parameter Object)

或

保持对象完整(Preserve Whole Object)

。

如果想要替换的数据值是类型码，而它并不影响行为，则可以运用

以类取代类型码(Replace Type Code with Class)

将它替换掉。如果你有与类型码相关的条件表达式，可运用

以子类取代类型码(Replace Type Code with Subclass)

或

以状态/策略模式取代类型码(Replace Type Code with State/Strategy)

加以处理。

如果你发现自己正从数组中挑选数据，可运用

以对象取代数组(Replace Array with Object)

。

收获：

多亏了使用对象替代基本数据类型，使得代码变得更加灵活。

代码变得更加易读和更加有组织。特殊数据可以集中进行操作，而不像之前那样分散。不用再猜测这些陌生的常量的意义以及它们为什么在数组中。

更容易发现重复代码。