在上一篇博客中，我们了解了不同类型的 Code Smells，我们还详细探讨了一种臃肿的代码气味，即 Long Method。 在这篇文章中，我们将继续讨论其他臃肿类型的代码气味，并提供更多示例。

1.大班

很多时候，在编程时，我们从一些小类开始，如下所示：

慢慢地，它随着每一个新功能的添加而变得更大..

而且更大……总之一团糟！

我们都无意中陷入了这种境地。解决方案很简单，但正如我们上次讨论的那样，我们首先要找出为什么这个大类是一个问题？

为什么要重构大类？

大类影响程序的可读性。随着时间的推移，很难维护这样的类。但是，除此之外，还有一个主要问题。当该类具有多个职责时，该类称为大类。它打破了单一职责原则，正如我们所知，可以更改大型类的原因不止一个。特别是，在上面给出的示例中，如果与客户相关的业务逻辑发生更改或客户的打印逻辑发生更改，则可以更改我们的 CustomerService 类。

你可能已经猜到了，解决这个问题的方法是——提取类。您可以在单独的类中提取出负责打印的成员变量和方法，例如 CustomerPrinter？ :) 根据情况，还有其他一些解决方案。如果要分离的类作为子类更有意义，则可以将该类提取为子类。但这对于这篇文章来说太过分了。我们将改用另一个臃肿的代码气味。

2.长参数列表

我们来看看下面的方法：

它有“太多”的参数。 （怎么说呢？一般准则说最多可以有 3-4 个参数，但除此之外，您应该开始重构）太多的参数不仅难以阅读，而且有时我们可能会忘记究竟哪个参数在哪个位置。所以我们可以很容易地将它们混合起来，即在调用该方法时，我们可以发送电话字符串而不是地址字符串，反之亦然。由于两者属于同一类型，因此可能会被忽视。这是唯一的问题吗？不。

这种代码异味的更深层次的问题是什么？

长参数列表并不孤单。它还表明我们可能在代码中存在其他代码异味，例如 - Primitive Obsession、Long 方法和 Data clumps。 （稍后我们将讨论原始痴迷。）这意味着我们可能没有正确识别系统中的“域对象”。

在此示例中，客户就是该对象。如果我们有一个包含所有必需信息（即姓名、地址、电话、年龄等）的 Customer 类，并且我们将 Customer 对象传递给此方法，我们的问题就解决了。

伟大的！我们得到了解决方案。这种重构解决方案被称为“保留整个对象”。如果我们还没有这个类，我们可以通过将原始字段分组到一个新类中来创建一个。它被称为“引入参数对象”。

3.原始痴迷

Primitive Obsession 意味着大量使用原始类型，如 int、string 等。这种代码异味和长参数列表异味齐头并进。 Primitive Obsession 可能会导致长参数列表问题。

它可以从小的开始。有时程序员会想“我只想添加一两个字段，我需要为此创建一个单独的类吗？”。随着时间的推移，它会慢慢增加。这些原始字段不断增加。我们在上一节中看到的 printCustomersBasicData 方法的示例可能从小尺寸开始。这就是为什么同样的解决方案——保留整个对象——也适用于 Primitive Obsession 问题。

假设我们创建了 Customer 类，如下所示：

但我们还没有完全解决原始痴迷的问题。 上述类中的字段性别可以有一组允许的值，例如男性、女性或 LGBTQ 社区的另一组值。 但除此之外，它不能有任何东西。 我的意思是性别不能是“XYZ”。 因此，我们可以创建它的类——也许是一个枚举类——来保存允许值的集合，而不是使用字符串原始类型来存储性别。

这种为类型代码设置一个单独的类的解决方案称为——用类替换类型代码。

这就是我这篇文章的全部内容。 我认为我们讨论了很多关于膨胀的内容。

谢谢你。 您的反馈对我来说很宝贵。

关注七爪网，获取更多APP/小程序/网站源码资源！