我有时会创建“ Util”类，这些类主要用于保存似乎并不真正属于其他地方的方法和值。但是每次创建这些类之一时，我都会想：“哦，哦，我以后会后悔的……”，因为我在某处读到不好。

但另一方面，似乎有两个令人信服的案例（至少对我而言）：

1. 包中多个类中使用的实现机密
2. 提供有用的功能来扩展类，而不会使其界面混乱

我要毁灭了吗？你说的话 ！！我应该重构吗？

现代OO设计接受并非所有事物都是对象。有些事情是行为或公式，而有些则没有状态。最好将这些事物建模为纯函数以从该设计中受益。

Java和C＃（及其他）和Java要求您创建一个util类，并跳过该箍以完成此操作。烦人，但世界末日却没有；从设计的角度来看并不是很麻烦。

永不说永不”

我不认为这一定是坏的，只有当您不好地做它并滥用它时，它才是坏的。

我们都需要工具和实用程序

首先，我们所有人都使用一些有时被认为是无处不在且必须具备的库。例如，在Java世界中，Google Guava或某些Apache Commons（Apache Commons Lang，Apache Commons Collections等）。

因此，显然需要这些。

避免硬语，重复和引入错误

如果你觉得这些都非常简单，只是一个非常大的一堆这些的Util类，您形容，除了有人通过竭尽全力去得到他们（相对）的权利，他们一直时间 - 测试和其他严重眼揉成团。

因此，当我想编写一个Util类的想法时，我想说的第一个经验法则是检查Util该类是否确实不存在。

我看到的唯一反论点是当您想限制依赖项时，因为：

• 您想限制依赖项的内存占用量，
• 或者您想严格控制开发人员的使用权限（在大型团队中会发生这种情况，或者某个特定的框架因拥有奇特的超级烂类而绝对避免在某个地方使用）。

但这两种情况都可以通过使用ProGuard或等效工具重新打包lib 或自己拆解来解决（对于Maven用户，maven-shade-plugin提供了一些过滤模式以将其集成为构建的一部分）。

因此，如果它在一个库中并且与您的用例匹配，并且没有基准告诉您，请使用它。如果它与您的内容有所不同，请对其进行扩展（如果可能）或进行扩展，或者在万不得已时将其重写。

命名约定

但是，到目前为止，在这个答案中，我称他们Util像您一样。不要这样命名。

给他们起有意义的名字。以Google Guava为例（非常非常好），然后想象一下，com.google.guava命名空间实际上就是您的util根。

util在最坏的情况下调用您的包，但不要调用类。如果处理String对象和字符串构造的操作，则将其命名为Strings，而不是StringUtils（抱歉，Apache Commons Lang-我仍然喜欢并使用您！）。如果它做了特定的事情，请选择一个特定的类名（如Splitter或Joiner）。

单元测试

如果必须使用这些实用程序，请确保对其进行单元测试。关于实用程序的好处是，它们通常是相当独立的组件，它们接受特定的输入并返回特定的输出。这就是概念。因此，没有理由不对它们进行单元测试。

此外，单元测试将允许您定义和记录其API合同。如果测试失败，则可能是您以错误的方式进行了某些更改，或者这意味着您正在尝试更改API的合同^{（或者您的原始测试已被废除，请从中吸取教训，不要再做）}。

API设计

您可能需要很长一段时间来遵循这些API的设计决策。因此，尽管不花很多时间在编写Splitter-clone上，但请谨慎对待问题。

问自己几个问题：

• 如果您的实用程序方法成为一组类似有用的方法的一部分，那么它是否可以单独保证一个类，还是静态方法足够好？
• 您是否需要工厂方法来创建对象并提高API的可读性？
• 说到可读性，您需要Fluent API，builders等吗？

您希望这些实用程序涵盖大量用例，健壮，稳定，有据可查，遵循最少惊讶的原则并且具有独立性。理想情况下，您的utils的每个子软件包，或至少整个util软件包，都应可导出到捆绑软件中，以便于重复使用。

和往常一样，在这里向巨人学习：

• 仔细检查这些内容，然后进行分析和比较，然后经常回到它们再做一次^{（请注意，我对这些文件的绝对或部分好坏没有做出任何判断，重点在于分析和比较位）}：
  • Java的util程序包（包含Collections库）及其等效的.Net，
  • Google Guava和Apache Commons，
  • C ++的STL和Boost，
  • Scala的收藏 库和scalaz，
  • 然后回到基础知识，看看goo ol'libC。
• 观看Josh Bloch的“ 如何设计良好的API及其重要性”（幻灯片）。
• 阅读并观看一些其他Bloch资料：
  • 有效的Java（Bloch，2008年），
  • Java Puzzlers（Bloch，Gafter，2005），
  • 创建Java对象。
• 阅读API设计事项。

^{是的，其中许多都强调集合和数据结构，但是请不要告诉我，通常您不是直接或间接实现大多数utils的地方或目的。}

实用程序类不是具有凝聚力的，并且通常是不良的设计，因为类必须具有更改的单一原因（单一责任原则）。

不过，我已经看到了“UTIL”非常的Java API的类，如：Math，Collections和Arrays。

实际上，它们是实用程序类，但它们的所有方法都与单个主题相关，一个具有数学运算，一个具有用于操纵集合的方法，另一个具有用于操纵数组的方法。

尽量不要在实用程序类中有完全不相关的方法。如果是这样，您也可以将它们放到它们真正属于的位置。

如果必须有util的类，然后试戴按主题进行分离像Java的Math，Collections和Arrays。至少，即使它们只是名称空间，也显示出一些设计意图。

首先，我总是避免使用实用程序类，并且从来不需要创建一个。

尽管我更喜欢util类，但完全可以接受util类ClassNameHelper。.NET BCL甚至包含帮助程序类。要记住的最重要的事情是，彻底记录类的用途以及每个单独的辅助方法，并使其成为高质量的可维护代码。

并且不要被助手类迷住了。

我使用两层方法。“ util”包（文件夹）中的“ Globals”类。为了使某些东西进入“ Globals”类或“ util”包，它必须是：

1. 简单，
2. 不变，
3. 不依赖您的应用程序中的任何其他内容

通过这些测试的示例：

• 系统范围的日期和十进制格式
• 不变的全局数据，例如EARLIEST_YEAR（系统支持）或IS_TEST_MODE或诸如此类的真正的全局且不变（在系统运行时）的值。
• 很小的帮助程序方法，可以解决您的语言，框架或工具包中的空白

这是一个非常小的助手方法的示例，它完全独立于应用程序的其余部分：

public static String ordinal(final int i) {
    return (i == 1) ? "1st" :
           (i == 2) ? "2nd" :
           (i == 3) ? "3rd" :
           new StringBuilder().append(i).append("th").toString();
}

看着这个，我可以看到一个错误，那就是21应该是“ 21st”，22应该是“ 22nd”，依此类推，但这并不重要。

如果这些辅助方法之一增长或变得复杂，则应将其移至util包中的自己的类。如果util程序包中的两个或更多帮助程序类相互关联，则应将它们移到自己的程序包中。如果事实证明常量或辅助方法与您的应用程序的特定部分相关，则应将其移到那里。

您应该能够证明为什么在Globals类或util包中粘贴的所有内容没有比这更好的地方了，并且应该使用上述测试定期对其进行清理。否则，您将造成混乱。