实用程序类静态方法和继承答案

【问题标题】：Utility class static methods and inheritance实用程序类静态方法和继承
【发布时间】：2011-05-19 02:42:43
【问题描述】：

我的应用程序有一个带有静态方法的实用程序类，这些方法负责显示通知并在发生错误时发送电子邮件：

public static void sendEvent(final String description, final String name) {
    ....
    SmtpParms smtpParams = readSmtpParms();
    ....
}

private static SmtpParms readSmtpParms() {
    // read from properties file
    ....
}

我们的代码库在两个应用程序之间共享。应用程序 A 从属性文件中读取 SMTP 参数。我主要在应用程序 B 上工作。应用程序 B 没有使用此电子邮件功能，但仍在调用以在我们的 GUI 上显示事件通知。现在应用程序 B 需要从数据库中读取 SMTP 参数。

我想重用现有代码，但由于方法是静态的，我不能只是子类化这个实用程序类并将所有应用程序 B 代码指向子类。这个实用程序在多个 JAR 中被引用，我更喜欢尽可能少地改变代码的解决方案。

我想如果我可以将readSmtpParms 分离到一个单独的类中，那可能会有所帮助。但是我想不出一种在不更改sendEvent 的方法签名的情况下将源（属性文件与数据库）传递给实用程序类实例的方法。我想另一种方法是创建另一个方法sendEventUsingDatabase，但我仍然需要更新应用程序 B 代码中对sendEvent 的所有引用。

有没有不修改原始代码又不重复代码的解决方案？此代码是否匹配设计模式或反模式？谢谢。

【问题讨论】：

标签： java design-patterns

【解决方案1】：

您引用了两个完全不同的行为案例（.properties 与数据库），这让我认为这些不应该是静态方法。您需要一个接口，应用程序 A 和 B 可以插入它们自己的自定义行为。

【讨论】：

即使只有“一种行为”，除了参数中的数据之外，这些方法仍在操作的数据仍然存在，因此它们不应该是静态的。

【解决方案2】：

静态实用程序方法不适合“发送电子邮件”的情况。

我建议你将代码重构为一个可以正确实例化的类，并将电子邮件配置参数作为输入。

为确保不破坏现有代码，然后重命名类并将其与用于从属性文件读取配置的代码一起包装在具有原始名称的类中。

现在您有了一个可以使用的类，并使用从 db 检索的配置加载，以及一个符合遗留代码中使用的静态实用程序方法签名的包装器。

【讨论】：

【解决方案3】：

当您尝试创建面向对象的应用程序时，Helper 类是万恶之源。所做的一切都是帮助您从函数式编程开始（类只不过是一个函数容器）。

尽量少用。

所以答案是你需要切换到另一种方法。

【讨论】：

【解决方案4】：

一旦你的类中有静态方法，测试就变得很困难。你将无法嘲笑。这是重构代码并摆脱静态方法的另一个原因。

【讨论】：