我正在研究一个用于解析 HTML 和生成 RDF 的 java 类（我想我最终将把它分成两个类——一个用于解析，一个用于生成 RDF）。
目前，我正在创建许多方法来检查 HTML 数据并将其转换为更统一的表示形式。到目前为止，我创建的一些方法是：
public boolean isInteger(String str) { }
public boolean isTime(String str) { }
public boolean isDate(String str) { }
public String dateConverter(String[] date) { } //Converts a Norwegian date into mmddYYYY
我应该将这样的方法放入 util 类中吗？目前它们只被这个特定的班级使用，但我认为他们可能需要在以后的某个时间点被不止一个班级使用。
好吧，是的，您列出的方法看起来很适合public staticutil 类中的方法。（例如，最后 2 或 3 个非常适合名为“DateUtils”的类。）
当然，如果你只在一个地方使用它们，它们也可以在那里保持“私人助手”，但是一旦你有多个地方使用它们，一个 util 类就有意义了。
（编辑：过度使用静态方法可能会有问题，但我认为这些方法很可能是静态工具，因为它们是纯函数。）
在实用程序类中收集此类方法是一种很好的做法。即使它们目前是从单个类中调用的，这些方法也可能会被其他客户端在附近功能中重用。
但是，您必须注意使该实用程序类易于重用。为此，方法签名，实际上是它们的参数，必须尽可能通用。他们不应该接受特定于某个类的输入。
我的另一个建议是将这个实用程序类划分为多个类，如果它开始包含许多不连贯的方法。您可以通过将相关方法分组到一个单独的类中来做到这一点。例如，您编写的方法可以移动到TypeUtils类中，您可以在类中收集转换相关的方法Html2RdfUtils。
最后，如果您觉得这些实用程序类对您的其他项目有益，您可以将它们收集到一个不同的库中。
它们看起来足够通用，适合放入 util 类。我会，至少。基本上任何在代码中解析 String 的类都需要使用这些方法。我会在将它们添加到类之前将它们设为静态，以避免不必要的构造。
分解是一个好习惯。如果您不确定是否需要使用它们，请继续使用它们。它将让您练习使用实用程序类。
如果您最终要将它们拆分为两个类，则可能需要将基类定义为接口或抽象类。
根据您的要求，抽象类应该是正确的选择。把子类的共同点放到抽象类中。（可以在抽象类中实现方法）
从另一个答案，我想问一个问题？答案建议将 static 放在方法前面以避免不必要的构造，这很有意义。
我知道抽象类不需要实例化来调用它的方法。它也可以避免施工。
有问题吗？哪种方式更合法？或更好？或者只是一样。