拥有一个MiscUtilities课程是不好的形式？

Question

我们公司保留一个MiscUtilities类,它只包含公共静态方法,这些方法通常执行不相关的任务,例如将日期从String转换为Calendar以及将ArrayLists写入文件.我们在其他类中引用它并发现它非常方便.但是,我见过那种公用事业类嘲笑TheDailyWTF.我只是想知道这类课程是否有任何实际的缺点,以及替代方案是什么.

Answer 1

我将引用Java社区中的权威来源,以及来自2个非常有信誉的第三方库的示例,而不是提供个人意见.

Effective Java 2nd Edition引用,第4项:使用私有构造函数强制执行非实例化:

有时你会想要编写一个只是一组static方法和static字段的类.这些课程的声誉很差,因为有些人滥用它们以避免在对象方面进行思考,但它们确实具有有效用途.它们可以被用来对原始值或阵列组相关的方法,在该方式java.lang.Math或java.util.Arrays.它们还可以用于对static实现特定接口的对象的方法(包括工厂方法)进行分组java.util.Collections.最后,它们可用于对final类进行分组,而不是扩展类.

Java库有许多这样的实用程序类的例子.

• Apache Commons Lang遵循命名约定 TypeUtils
  • ArrayUtils,StringUtils,ObjectUtils,BooleanUtils,等
• Guava遵循命名惯例 Types
  • Objects,Strings,Throwables,Collections2,Iterators,Iterables,Lists,Maps,等.
  • 该包的摘要实际上有对类的特定部分static的实用方法
  • 另外整个包包括什么,但实用工具类与Java的原始工作,Ints,Floats,Booleans,等.

简短的摘要

• 总是喜欢好的OOP设计
• static工具类具有有效的用途来组对相关的方法:
  • 基元(因为它们不是对象)
  • 接口(因为它们不能有任何具体的东西)
  • final 类(因为它们不可扩展)
• 总是喜欢良好的组织
  • 组工具方法SomeType来或SomeTypeUtilsSomeTypes
  • 避免使用包含不同类型/概念上的各种不相关任务的单个大型实用程序类

Answer 2

对于支持函数的语言来说，这种类无疑是不好的形式。

对于不这样做的语言，这种类不是，并且可能优于使用随机实用方法扩展其他类。静态实用方法，因为它们位于其他类中，所以只能使用它们处理的对象的公共接口，这减少了出现某些类型错误的可能性。这种方法还避免了随机收集当时人们碰巧发现有用的东西来污染公共界面。

当然，这涉及一定程度的个人风格。我不太相信能提供一切的类（即使是 C++ 的功能也std::string有点过于我的口味），并且倾向于将辅助功能作为单独的函数。使类的维护变得更容易，迫使公共接口变得有用和高效，并且通过鸭子类型风格机制，外部函数可以在多种类型中使用，而无需复制源文本或共享基类等。（C++ 标准库中经常被嘲笑的算法很好地证明了这一点，尽管它们并不完美且冗长。）

也就是说，我和许多人一起工作过，他们抱怨字符串不知道如何将自己解释为文件名，或者将自己拆分成单词，或者你有什么，等等。（我选择字符串是因为它们似乎是实用函数的主要目标......）我碰巧认为，拥有这样的大型类会带来看不见的维护和可靠性成本，除了名义上简单的类的丑陋之外这实际上是一个不相关的问题的巨大不合逻辑的大杂烩，它们肮脏的手指最终把自己戳进了每一个角落——因为你的自我标记字符串需要某种容器来放入标记，对吧？！——但这是一种平衡行为，即使我的措辞表明它比这更清晰。

我不太相信“OO 教条”的概念，但也许偏执狂可能会看到它在这里起作用。没有充分的理由认为所有功能都应该附加到特定的类，并且有很多充分的理由说明为什么不应该这样做。但是某些语言仍然不允许创建函数，这并不能消除对函数的需求，并且迫使人们通过创建只包含静态方法的类来解决该限制。在我看来，这相当超载了类概念的含义，而且没有任何好处。

因此，这是反对这种做法的一个很好的理由，但除非语言发生变化以适应人们需要做的事情，否则这是徒劳的。语言并不是没有功能的，除非它们的设计者别有用心，或者有技术原因，所以我认为这两种情况都不太可能发生改变。

我想执行摘要是：不。