实用工具类静态方法和继承

Question

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

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参数。

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

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

有没有一个解决方案不会改变原始代码，但也不会重复代码？ 此代码是否与设计模式或反模式匹配？ 谢谢。

Answer 1

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

Answer 2

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

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

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

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

Answer 3

当您尝试创建面向对象的应用程序时，帮助程序类是所有邪恶的根源。 所有这些都可以帮助您从函数式编程开始（该类只不过是一个函数容器）。

尝试尽可能少地使用。

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

Answer 4

只要您在类中使用静态方法，测试就变得很困难。 你不能嘲笑。 这是重构代码并摆脱静态方法的另一个原因。