Warum nicht statische Methoden für externe Ressourcen verwenden?

Question

Ich bin ein Fan von statischen Methoden in Java für zB in Util-Klassen. Aber unter einigen Kollegen habe ich einige Argumente gefunden, dass eine statische Methode niemals externe Ressourcen verwenden sollte. Aber niemand konnte erklären, warum es schlecht oder sogar gefährlich sein sollte. Der einzige Grund, den ich gefunden habe, ist, dass es schwierig sein kann, diese externe Ressource während des Tests zu verspotten. Aber ist das wirklich der einzige Grund?

Im Folgenden habe ich ein Beispiel für eine statische Methode. Ich würde gerne verstehen, warum es ein schlechter Ansatz sein sollte, um es mit statischen zu verwenden.

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; 
    } 
} 

Mit freundlichen Grüßen

Answer 1

betrachten zwei Klassen

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); 
} 

} 

Klasse Foo Utility-Klasse verwendet, während Klasse Bar-Klasse verwendet, die Sender-Schnittstelle implementiert.

erstens, wie Sie in Ihrer Frage erwähnen, ist es viel einfacher, Absender für Testzwecke zu verspotten. Andernfalls müssen Sie eine Infrastruktur erstellen, die eine Nachricht zur Validierung des gesamten Prozesses empfangen kann.

Zweitens, verlieren Sie die Möglichkeit, die Funktionalität zu abstrahieren. Stellen Sie sich eine Situation vor, in der Sie die Art und Weise ändern müssen, wie Sie eine Nachricht senden. Im ersten Fall müssen Sie Änderungen in der Klasse vornehmen, die die Logik Ihres Systems verarbeitet. In der Sekunde, in der Sie den Prozess des Sendens der Nachricht abstrahiert haben, müssen Sie alles, was Sie tun müssen, im Modul ändern, das für das Bootstrapping Ihrer Anwendung verantwortlich ist. in einigen Fällen diese Änderung vielleicht in Ihrer Konfigurationsdatei getan und auf Live-System

Answer 2

Das Hauptproblem mit statischen Methoden ist, dass Sie die Implementierung nicht leicht ändern können. Statische Methoden können keine Schnittstellen haben.

Das ist aus vielen Gründen schlecht, aber konzentrieren wir uns auf den Zugriff auf externe Ressourcen.

Mit statischen Methoden wird die Testbarkeit zu einem großen Problem. Entweder benötigen Sie die externe Ressource für Tests ODER Sie testen "herum" Ihre statischen Methoden. Wenn Sie stattdessen eine Schnittstelle MessageSender hätten, könnten Sie dies im Test leicht nachahmen und nur prüfen, ob es wie erwartet aufgerufen wurde.

Dann müssen Sie manchmal den Zugriff auf externe Ressourcen einrichten. Wenn Sie beispielsweise einen REST-Client zum Nachschlagen haben, können Sie später entscheiden, Caching hinzuzufügen, um die Leistung zu verbessern. Dies ist viel einfacher mit Schnittstellen.