用实例告诉你如何重构带有坏味道的代码

如果出现了代码坏味道,说明你的代码写得不够好,需要重构才能让它们变成干净的代码。在这篇文章中,我将通过 GitHub 上的真实项目来解释代码坏味道,并向你展示如何重构这些带有坏味道的代码。

为东湖等地区用户提供了全套网页设计制作服务,及东湖网站建设行业解决方案。主营业务为网站建设、成都做网站、东湖网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!

重复代码和重复逻辑

开发人员通常很懒惰,在某种程度上,这不算一件坏事。然而,因为懒惰而走上了复制黏贴代码的不归路那就不对了。这样可能会导致最常见的代码坏味道,即逻辑重复,如下所示。

为了摆脱这种代码坏味道,我们需要将红色部分提取到一个单独的方法中,这样就可以在其他地方重用它们。

长方法和臃肿的类

我们都会犯这样的一个错误:在现有方法中添加 if() 或 for() 语句来验证用户输入或检查用户是否已登录。我们其实不应该这样做。如果一定要做这些验证,应该创建自己的方法。方法长度应该在 4 到 20 行之间,如果超过 20 行,可以将其中的几行提取到另一个方法中。同样的规则也适用于类,根据单一责任原则,方法或类越小越好。

相同或不同类中的重复方法

另一个代码坏味道是多个方法提供了相同的功能,如下图所示。

分散式变更(Divergent Change)

如果你了解 SOLID 原则,特别是单一职责原则,那么你就应该知道,修改一个类的理由应该是单一的。也就是说,User 类不应具有与产品或文件转换相关的功能。你可以通过将不相关的方法提取到 Product 类或 FileSystem 类来清除这个代码坏味道。

散弹式变更(Shotgun Surgery)

这与发散变更完全相反。这种代码坏味道会让你因为一个需求而去修改多个类。例如,你想要创建一个新的用户规则(如“Supper-Admin”),然后你发现,为了增加这个规则还需要修改 Profile、Products 和 Employees 类中的某些方法。在这种情况下,可以考虑将这些方法放在一个单独的类中。

依恋情结(Feature Envy)

有时候,你会在类中找到一个大量使用另一个类的方法。在这种情况下,你可以考虑将这个方法移动到它使用的那个类中。如下图所示。将 getFullAddress() 从 User 类移动到 ContactInfo 类中岂不是更好?因为它调用了 ContactInfo 类的很多方法。

数据泥团(Data Clumps)

有时候,你会发现很多函数具有相同的参数列表,这样会导致数泥团代码坏味道。看看下面的例子,你会发现,几乎所有类型的预订都需要护照信息。

在这种情况下,将护照信息移到 PassportInfo 类中,然后将 PassportInfo 对象传给预订方法,这样会更好。这是一个很好的重用代码的例子。请记住,参数列表太长可能更容易导致 bug 和代码冲突,而且难以进行单元测试。

痴迷基本类型(Primitive Obsession)

当你在应用程序的所有地方都使用基本数据类型时,就会出现这种代码坏味道。例如,使用整数表示电话号码,使用字符串表示货币符号。如果你是这么做的,那么请先看一下下面这个类。

代码中的地址被定义为数组,这样会导致两个问题,例如,每次我们需要使用地址时都要对其进行硬编码。那么,为什么不创建一个 Address 类呢?

现在,每次我们需要添加或编辑地址时,只需要修改 Address 类。此外,如果我们需要添加一个新的“联系我们”方法,就增加一个新的 ContactUs 类。这样,每个类都有自己的单一职责。

switch 语句

或许你很想知道为什么使用 switch 语句其实是件很糟糕的事情。虽说使用 switch 语句并不一定总是不好的,但在下面的示例中,你可以看到,switch 语句的代码块不仅很大而且是不可提取的。当代码块变得越来越大时,你将无法将其拆分成更小的方法。

如果你的 switch 语句代码块不是很大,那么你可以继续使用它们。例如,工厂模式就使用了 switch 语句。

并行继承

有时候我会想,并行继承是不是一种不好的做法。先让我们来解释一下并行继承的概念,然后再讨论它是不是代码坏味道。

从上图中可以看出,每当我们创建一个新的部门类时,我们还需要创建一个权限类,这将导致之前提到的散弹式变更代码坏味道。

懒惰类

懒惰类是指只做很少事情的类。还记得这些下面这些代码吗?

我们将地址移到一个单独的类中,但我们没有对热线也这么做,因为它可能只有 3 行代码。所以,一旦你发现了这些懒惰类,应该将它们移除。

临时字段

当一个类实例的某些变量只是偶尔用到,就出出现临时字段代码坏味道。请看下面的例子,你会注意到 $name 和 $contactDetails 只在 notify() 方法中用到。

那么为什么不将它们作为方法参数进行传递呢。

消息链

当一个类使用了另一个类,而那个类又使用了另外一个类,并以此类推,那么就会出现消息链代码坏味道。在下图中,你可以看到 Employee->EmployeeConfig->Config。

你可以通过缩短链(变成 Employee->Config)让代码变得更整洁。

不恰当的亲密关系

有时候,一个类的某个方法需要过多地了解另一个类的内部状态或数据。正如你在下图中所看到的,notify() 方法位于 User Class 中,但它却使用了 UserContactDetails 类的很多内部方法。

在这种情况下,***可以将这些逻辑从 User 类移动到 UserContactDetails 类中,并新增 getWelcomeMessage($userName) 方法。

中间人

有时候,你会发现一个类的很多方法什么事都不做,只是将调用委托给另一个类。在这种情况下,这个类被认为是中间人,大多数时候可以避免使用它。

注意:在 Facade 设计模式中,中间人在某些情况下可能会有所帮助。

接口不同但目的相同的类

通常,因为团队之间缺乏沟通,创建了两个不同的类,但它们的作用却是一样的,这意味着出现了重复代码。

不完整的库

第三方库并不总能为你提供应用程序中所需的所有功能。在下面的示例中,处理文档的库可以通过 ID 获取一个文档或一次获取所有的文档。

如果你需要获取特定用户的所有文档该怎么办?在这种情况下,你需要扩展 Document 类的功能,而不直接修改原始类。这个时候可以使用装饰模式,如下图所示。

现在,你可以使用 DocumentsDecorator 类而不是 Documents 类。

注释

你可能会感到惊讶,但错误地使用注释也是一种代码坏味道。下面是我的一些建议:

  • 删除不必要的注释。
  • 如果代码很容易理解,请不要添加额外的注释。
  • 不要留下被注释的旧代码。
  • 删除用于调试的注释,如 var_dump、echo 等。

夸夸其谈未来性(Speculative Generality)

这个代码坏味道与过早进行优化有关,很多开发人员都没有注意到这一点。在规划期间需要考虑的一些注意事项:

  • 不要过度计划你的代码。
  • 不要试图涵盖只有 1%可能性会在未来发生的情况。
  • 为了让算法更简单,可以牺牲一些速度,特别是当你不需要应用程序立即给出结果的时候。
  • 当应用程序速度很慢,即使只有 100 个用户,也需要进行优化。

英文原文:https://codeburst.io/write-clean-code-and-get-rid-of-code-smells-aea271f30318 

【责任编辑:庞桂玉 TEL:(010)68476606】

本文标题:用实例告诉你如何重构带有坏味道的代码
网站地址:http://www.mswzjz.com/qtweb/news28/182678.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联