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

我的应用程序有一个带有静态方法的实用程序类，该类负责在发生错误时显示通知和选择性地发送电子邮件：

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

的方法签名的情况下，将源代码（属性文件与数据库）传递给实用程序类实例。我想另一种方法是使用Database创建另一个方法

sendEvents

，但是我仍然需要更新应用程序B代码中对

sendEvent

的所有引用

---

是否有一种既不改变原始代码又不复制代码的解决方案？此代码与设计模式或反模式匹配吗？谢谢。

您列举了两个行为截然不同的案例（.properties vs database），这让我觉得这些不应该是静态方法。您需要一个接口，应用程序A和B可以插入它们自己的自定义行为

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

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

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

---

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

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

尽量少用

---

因此，答案是您需要切换到另一种方法。

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

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