这么简单的方法怎么分解命名？答案

【问题标题】：How can such a simple method be broken down and named?这么简单的方法怎么分解命名？
【发布时间】：2015-07-10 22:42:00
【问题描述】：

最佳实践不断地规定，一个方法应该只对一件事负责。我遇到了一种做 3 件事的方法，但我不知道如何 1. 根据最佳实践分解它。 2. 命名。另外我想知道现实生活中有多少方法真的只做一件事，就像教科书一直建议的那样？

method ( entryId ) {
   if (this.checkDuplicate(entryId)) {
       this.deleteDuplicate(entryId);
       return true;
   } else {
       return false;
   } 
}

正如我们所见，名为 method 的方法不仅仅做一件事。是否甚至可以遵守“方法应该只对一件事负责”的规则？

如果是，上面的算法怎么分解成呢？

如果不是，我能命名一个能做这么多事情的方法吗？

【问题讨论】：

您可能希望深入了解这一点，您基本上是在说永远不应该使用 if 语句。你应该问自己的是method 函数名只做一件事吗？例如，您不需要执行 UpdateDataBase 和发送电子邮件的方法。
从技术上讲，这种方法甚至不应该存在，因为deleteDuplicate(entryId) 应该检查是否有要删除的内容！如果您以这种方式保留此方法，checkDuplicate(entryId) 将被调用两次：通过方法和 deleteDuplicate

标签： java methods coupling cohesion

【解决方案1】：

让我们这样说吧 - 该规则（GRASP - 高内聚模式）与您的编程语言语义或语法无关。相反，这意味着您必须从更像功能或业务逻辑的角度小心处理您的方法/类职责。几乎所有的设计原则都必须以非常谨慎和谨慎的方式应用，否则你最终会得到几十个没有真正目的的间接和抽象层。

【讨论】：

【解决方案2】：

虽然 Yauheni Maltsau 写的是真的，但我想加上我的 10 美分。

我想说你的方法实际上只做一件事：检查重复并删除它。所以我会保持这样，除了名字。您应该给它一个更具描述性的名称，例如 removeIfDuplicate 或类似的名称。

【讨论】：

【解决方案3】：

您不一定要以完美的名称和完美的凝聚力开始。如果您有单元测试来验证代码的行为，您可以分几个阶段进行重构，并且在重构过程中您可能会多次更改名称。这个想法是在不破坏任何东西的情况下逐渐改进事物。

我可能首先将方法命名为“deleteEntryIfDuplicate”，然后我会问自己为什么该方法需要返回一个布尔值。由于我没有使用布尔值的调用代码，我只能推测，但可能有一个责任没有在正确的地方处理。例如，可能不是返回布尔值，而是应该在一个方法中处理重复条目的所有功能，该方法执行删除、记录并通知侦听器。这看起来像是增加了责任，但管理重复条目的情况可以被视为一项责任。烤蛋糕是一项单一的责任，即使这意味着您需要从冰箱中取出鸡蛋和牛奶，从储藏室中取出面粉和糖，预热烤箱等。目标是让每个电话都在正确的抽象级别。

我应该补充一点，您不必“镀金”一切。工程是关于权衡的。从长远来看，清晰的职责分离代码可以节省时间和金钱，但您可能不会有无限的时间来完善和完善所有内容。

【讨论】：