Question

我是java中静态方法的粉丝，例如在Util-classes中。但是在一些同事中，我遇到了一些静态方法永远不应该使用外部资源的论点。但没有人可以解释为什么它应该是坏的甚至是危险的。我发现的唯一原因是在测试期间可能很难模拟外部资源。但这真的是唯一的原因吗？

下面我得到了一个静态方法的例子。我很想理解为什么在静态时使用它应该是一个糟糕的方法。

public class JmsUtil {
    public static String sendBytesMessage(byte[] messageBytes) throws JMSException, NamingException {
        String jmsMessageID = null;
        Connection connection = null;
        try {
            Context context = new InitialContext();
            ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup("ourfactory");
            Queue queue = (Queue) context.lookup("ourqueue");

            connection = connectionFactory.createConnection();
            Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
            MessageProducer messageProducer = session.createProducer(queue);
            BytesMessage bytesMessage = session.createBytesMessage();
            bytesMessage.writeBytes(messageBytes);

            messageProducer.send(bytesMessage);
            jmsMessageID = bytesMessage.getJMSMessageID();    
        } finally {
            if (connection != null) {
                connection.close();
            }
        }
        return jmsMessageID;
    }
}

祝你好运

Answer 1

考虑两个班级

class Foo extends Blob{

public void someMethod(){
byte[] message = createMessage(); 
JmsUtil.sendBytesMessage(message);
}

}

class Bar extends Blob{
Sender sender;

public void someMethod(){
byte[] message = createMessage(); 
sender.sendBytesMessage(message);
}

}

类Foo使用实用程序类，而类Bar使用实现Sender接口的类。

首先，正如您在问题中提到的，模拟发件人更容易进行测试。否则你需要创建可以接收消息以验证整个过程的基础设施。

第二件事，你正在失去抽象功能的可能性。想象一下您需要改变发送消息的方式。在第一种情况下，您需要在类中进行修改以处理系统的逻辑。第二，当您抽象发送消息的过程时，您需要做的所有事情都在模块中进行更改，负责引导您的应用程序。在某些情况下，可能会在配置文件中完成更改并在实时系统上完成

Answer 2

静态方法的主要问题是您无法轻松更改实现。静态方法不能有接口。

这有很多原因，但让我们专注于访问外部资源。

使用静态方法，可测试性成为一个大问题。要么需要外部资源进行测试，要么“围绕”静态方法进行测试。如果你有一些MessageSender接口，你可以在测试中轻松模拟它，只检查它是否按预期调用。

然后，您有时可能需要修饰对外部资源的访问权限。例如，如果您有一些查找REST客户端，您可能稍后决定添加缓存以提高性能。使用接口可以轻松完成。

为什么不对外部资源使用静态方法？

2 个答案: