¿Cuál es un buen caso de uso para la importación estática de métodos?


137

Acabo de recibir un comentario de revisión de que mi importación estática del método no era una buena idea. La importación estática era de un método de una clase DA, que tiene principalmente métodos estáticos. Entonces, en medio de la lógica de negocios, tuve una actividad da que aparentemente parecía pertenecer a la clase actual:

import static some.package.DA.*;
class BusinessObject {
  void someMethod() {
    ....
    save(this);
  }
} 

El revisor no estaba interesado en cambiar el código y no lo hice, pero estoy de acuerdo con él. Una razón dada para no importar estáticamente fue que era confuso el lugar donde se definió el método, no estaba en la clase actual y no en ninguna superclase, por lo que es demasiado tiempo para identificar su definición (el sistema de revisión basado en la web no tiene clics) enlaces como IDE :-) Realmente no creo que esto importe, las importaciones estáticas todavía son bastante nuevas y pronto todos nos acostumbraremos a localizarlas.

Pero la otra razón, con la que estoy de acuerdo, es que una llamada a un método no calificado parece pertenecer al objeto actual y no debe saltar los contextos. Pero si realmente perteneciera, tendría sentido extender esa superclase.

Entonces, ¿cuándo tiene sentido los métodos de importación estáticos? Cuando lo has hecho ¿Te gustó / te gusta cómo se ven las llamadas no calificadas?

EDITAR: La opinión popular parece ser que los métodos de importación estática si nadie los va a confundir como métodos de la clase actual. Por ejemplo, métodos de java.lang.Math y java.awt.Color. Pero si abs y getAlpha no son ambiguos, no entiendo por qué readEmployee sí lo es. Como en muchas opciones de programación, creo que esto también es una preferencia personal.

Gracias por su respuesta chicos, estoy cerrando la pregunta.


2
Este es un muy buen uso de las importaciones estáticas: ibm.com/developerworks/library/j-ft18
intrepidis

1
@ mr5 la sintaxis es import static, la característica esstatic import
Variable miserable

Respuestas:


150

Esto es de la guía de Sun cuando lanzaron la función (énfasis en el original):

Entonces, ¿cuándo debería usar la importación estática? Muy escasamente! Úselo solo cuando de lo contrario estaría tentado a declarar copias locales de constantes o abusar de la herencia (el antipatrón de interfaz constante). ... Si usa en exceso la función de importación estática, puede hacer que su programa sea ilegible e imposible de mantener, contaminando su espacio de nombres con todos los miembros estáticos que importe. Los lectores de su código (incluido usted, unos meses después de que lo escribió) no sabrán de qué clase proviene un miembro estático. Importar todos los miembros estáticos de una clase puede ser particularmente dañino para la legibilidad; Si solo necesita uno o dos miembros, impórtelos individualmente.

( https://docs.oracle.com/javase/8/docs/technotes/guides/language/static-import.html )

Hay dos partes que quiero mencionar específicamente:

  • Utilice las importaciones estáticas solo cuando haya tenido la tentación de "abusar de la herencia". En este caso, ¿habría tenido la tentación de tener BusinessObject extend some.package.DA? Si es así, las importaciones estáticas pueden ser una forma más limpia de manejar esto. Si nunca hubiera soñado con extender some.package.DA, entonces este es probablemente un mal uso de las importaciones estáticas. No lo use solo para guardar algunos caracteres al escribir.
  • Importar miembros individuales. Decir en import static some.package.DA.savelugar de DA.*. Eso hará que sea mucho más fácil encontrar de dónde proviene este método importado.

Personalmente, he usado esta característica del lenguaje muy raramente, y casi siempre solo con constantes o enumeraciones, nunca con métodos. La compensación, para mí, casi nunca vale la pena.


9
Convenido. He usado importaciones estáticas muuuuy ocasionalmente donde realmente han hecho que el código sea mucho más fácil de seguir.
Neil Coffey el

65

Otro uso razonable para las importaciones estáticas es con JUnit 4. En versiones anteriores de los métodos JUnit, como assertEqualsy failse heredaron desde que se extendió la clase de prueba junit.framework.TestCase.

// old way
import junit.framework.TestCase;

public class MyTestClass extends TestCase {
    public void myMethodTest() {
        assertEquals("foo", "bar");
    }
}

En JUnit 4, las clases de prueba ya no necesitan extenderse TestCasey en su lugar pueden usar anotaciones. Luego puede importar estáticamente los métodos de aserción desde org.junit.Assert:

// new way
import static org.junit.Assert.assertEquals;

public class MyTestClass {
    @Test public void myMethodTest() {
        assertEquals("foo", "bar");
        // instead of
        Assert.assertEquals("foo", "bar");
    }
}

JUnit documentos utilizándolo de esta manera.


44
Estoy de acuerdo Simplificar los casos de prueba es un lugar donde la intención es poco probable que se malinterprete.
Bill Michell el

66
Hemos tenido esto en nuestro proyecto y en realidad hemos tenido problemas con las personas que usan asir () y piensan incorrectamente que proviene de su importación estática del paquete Assert. Una vez que encontramos este problema, un escaneo rápido de nuestra base de código encontró alrededor de 30 instancias de esto en nuestras pruebas, lo que significa que NO se ejecutaron 30 aserciones cuando se ejecutó el marco de prueba porque el indicador DEBUG no se establece cuando ejecutamos pruebas.
Chris Williams

27

Effective Java, segunda edición , al final del artículo 19 notas que se pueden utilizar las importaciones estáticas si usted se encuentra en gran medida el uso de las constantes de una clase de utilidad. Creo que este principio se aplicaría a las importaciones estáticas de constantes y métodos.

import static com.example.UtilityClassWithFrequentlyUsedMethods.myMethod;

public class MyClass {
    public void doSomething() {
        int foo= UtilityClassWithFrequentlyUsedMethods.myMethod();
        // can be written less verbosely as
        int bar = myMethod();
    }
}

Tiene sus ventajas y desventajas. Hace que el código sea un poco más legible a costa de perder información inmediata sobre dónde se define el método. Sin embargo, un buen IDE le permitirá ir a la definición, por lo que este no es un gran problema.

Todavía debe usar esto con moderación, y solo si se encuentra usando cosas del archivo importado muchas, muchas veces.

Editar: actualizado para ser más específico a los métodos, ya que a eso se refiere esta pregunta. El principio se aplica independientemente de lo que se importe (constantes o métodos).


1
Mi pregunta es sobre métodos de importación estática , no campos.
Variable miserable

77
Quizás UtilityClassWithFrequentlyUsedMethodsnecesita ser acortado.
Steve Kuo


@ Rob-Hruska ¿No podría simplemente envolver un método o campo de importación estático en un nuevo método o campo si planeo usarlos con frecuencia? ¿Eso me permitiría no importar estáticamente? tales como: double myPI = Math.PI;y luego puedo seguir refiriéndome en myPIlugar de Math.PI.
Abdul

@ Abdul - Sí, podrías hacer eso.
Rob Hruska

14

Estoy de acuerdo en que pueden ser problemáticos desde una perspectiva de legibilidad y deben usarse con moderación. Pero cuando se usa un método estático común, en realidad pueden aumentar la legibilidad. Por ejemplo, en una clase de prueba JUnit, los métodos como assertEqualsson obvios de dónde provienen. Del mismo modo para los métodos de java.lang.Math.


55
¿Y qué tiene de malo ver Math.round (d) versus round (d)?
Steve Kuo el

55
@SteveKuo: por la misma razón que los matemáticos usan nombres de variables de una letra cuando manipulan fórmulas: hay ocasiones en que los nombres más largos interfieren con la legibilidad de la declaración general. Considere una fórmula que involucra múltiples funciones trigonométricas. Una fórmula matemática fácilmente captado: sin x cos y + cos x sin y. En Java se convierte en: Math.sin(x) * Math.cos(y) + Math.cos(x) * Math.sin(y). Horrible de leer.
ToolmakerSteve

@ToolmakerSteve, por eso me perdí tanto la usingdirectiva en C ++: pueden ser locales .
Franklin Yu

11

Creo que la importación estática es realmente útil para eliminar nombres de clase redundantes cuando se usan clases de utilidades como Arraysy Assertions.

No estoy seguro de por qué, pero Ross omitió la última oración que menciona esto en la documentación a la que hace referencia .

Si se usa adecuadamente, la importación estática puede hacer que su programa sea más legible, al eliminar la repetitiva repetición de los nombres de clase.

Básicamente copiado de este blog: https://medium.com/alphadev-thoughts/static-imports-are-great-but-underused-e805ba9b279f

Así por ejemplo:

Afirmaciones en pruebas

Este es el caso más obvio en el que creo que todos estamos de acuerdo.

Assertions.assertThat(1).isEqualTo(2);

// Use static import instead
assertThat(1).isEqualTo(2);

Clases de utilidades y enumeraciones

El nombre de la clase se puede eliminar en muchos casos cuando se utilizan clases de utilidades que hacen que el código sea más fácil de leer

List<Integer> numbers = Arrays.asList(1, 2, 3);

// asList method name is enough information
List<Integer> numbers = asList(1, 2, 3);

El paquete java.time tiene algunos casos en los que debería usarse

// Get next Friday from now, quite annoying to read
LocalDate.now().with(TemporalAdjusters.next(DayOfWeek.FRIDAY));

// More concise and easier to read
LocalDate.now().with(next(FRIDAY));

Ejemplo de cuándo no usar

// Ok this is an Optional
Optional.of("hello world");

// I have no idea what this is 
of("hello world");

10

Lo uso mucho para Color.

static import java.awt.Color.*;

Es muy poco probable que los colores se confundan con algo más.


1
Ese es uno de los mejores casos de uso que he visto que difiere del antiguo JUnit / Hamcrest / TestNG.
kevinarpe

3

Recomiendo el uso de importación estática cuando se utiliza OpenGL con Java, que es un caso de uso caer en el "uso intensivo de las constantes de una clase de utilidad" categoría

Considere eso

import static android.opengl.GLES20.*;

le permite portar el código C original y escribir algo legible como:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texture);
glUniform1i(samplerUniform, 0);
glBindBuffer(GL_ARRAY_BUFFER, vtxBuffer);
glVertexAttribPointer(vtxAttrib, 3, GL_FLOAT, false, 0, 0);

en lugar de esa fealdad generalizada común:

GLES20.glActiveTexture(GLES20.GL_TEXTURE0);
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, texture);
GLES20.glUniform1i(samplerUniform, 0);
GLES20.glBindBuffer(GLES20.GL_ARRAY_BUFFER, vtxBuffer);
GLES20.glVertexAttribPointer(vtxAttrib, 3, GLES20.GL_FLOAT, false, 0, 0);

2

Las importaciones estáticas son la única característica "nueva" de Java que nunca he usado y que no pretendo usar, debido a los problemas que acaba de mencionar.


Gracias bombe Bueno, creo que tienen más sentido que tengan que extenderse y una interfaz que solo contiene un montón de finales estáticos.
Variable miserable

2

Utilizo 'import static java.lang.Math. *' Al portar código pesado matemático de C / C ++ a java. Los métodos matemáticos se asignan del 1 al 1 y facilitan la diferenciación del código portado sin la calificación del nombre de la clase.


2

Encontré que esto es muy conveniente cuando utilizo las clases de utilidad.

Por ejemplo, en lugar de usar: if(CollectionUtils.isNotEmpty(col))

En cambio puedo:

import static org.apache.commons.collections.CollectionUtils.isNotEmpty;
if(isNotEmpty(col))

Qué IMO aumenta la legibilidad del código cuando uso esta utilidad varias veces en mi código.


2

Hablando de pruebas de unidad: la mayoría de las personas utilizan las importaciones estáticas para los diversos métodos estáticos que burlones marcos proporcionan, tales como when()o verify().

import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

Y, por supuesto, cuando se utiliza la única afirmación de que debería estar utilizándola assertThat(), resulta útil importar de forma estática los emparejadores de hachas, como en:

import static org.hamcrest.Matchers.*;

1

Son útiles para reducir la palabrería, particularmente en los casos en que se llaman muchos métodos importados, y la distinción entre métodos locales e importados es clara.

Un ejemplo: código que involucra múltiples referencias a java.lang.Math

Otro: una clase de constructor XML donde anteponer el nombre de clase a cada referencia ocultaría la estructura que se está construyendo


1

Creo que las importaciones estáticas están ordenadas para NLS en el estilo gettext.

import static mypackage.TranslatorUtil._;

//...
System.out.println(_("Hello world."));

Esto marca la cadena como una cadena que debe extraerse y proporciona una manera fácil y limpia de reemplazar la cadena con su traducción.


1

La importación estática de IMO es una característica bastante agradable. Es absolutamente cierto que la gran dependencia de la importación estática hace que el código sea ilegible y difícil de entender a qué clase pertenece un método o atributo estático. Sin embargo, en mi experiencia se convierte en una característica utilizable, especialmente al diseñar Utilclases que proporcionan algunos métodos y atributos estáticos. La ambigüedad que surge cada vez que se proporciona importación estática se puede eludir estableciendo estándares de código. En mi experiencia dentro de una empresa, este enfoque es aceptable y hace que el código sea más limpio y fácil de entender. Preferiblemente inserto el _carácter en métodos estáticos frontales y atributos estáticos (de alguna manera adoptado de C). Aparentemente, este enfoque viola los estándares de nomenclatura de Java, pero proporciona claridad al código. Por ejemplo, si tenemos una clase AngleUtils:

public class AngleUtils {

    public static final float _ZERO = 0.0f;
    public static final float _PI   = 3.14f;

    public static float _angleDiff(float angle1, float angle2){

    }

    public static float _addAngle(float target, float dest){

    }
}

En este caso, la importación estática proporciona claridad y la estructura del código me parece más elegante:

import static AngleUtils.*;

public class TestClass{

    public void testAngles(){

        float initialAngle = _ZERO;
        float angle1, angle2;
        _addAngle(angle1, angle2);
    }
}

De inmediato, alguien puede saber qué método o atributo proviene de una importación estática y oculta la información de la clase a la que pertenece. No sugiero usar la importación estática para clases que son parte integral de un módulo y proporcionan métodos estáticos y no estáticos, ya que en este caso es importante saber qué clase proporciona cierta funcionalidad estática.


Gracias por la sugerencia de cambiar el nombre. Por cierto, un guión bajo al frente se usa tradicionalmente en algunos entornos para nombrar métodos / campos privados. Estoy considerando una convención modificada, como H_para las importaciones de una Helperclase de utilidad que tengo, o C_para Common, o U_para Utility. Alternativamente, he considerado usar nombres de clase de uno o dos caracteres para estas clases ampliamente utilizadas, pero me preocupaba que a veces pudieran entrar en conflicto con los nombres locales: tener algún código heredado con nombres de métodos en mayúsculas.
ToolmakerSteve

-1

Debe usarlos cuando:

  • desea utilizar una switchdeclaración con valores de enumeración
  • desea que su código sea difícil de entender

9
Esto no es verdad. (1) Puede usar constantes de enumeración perfectamente bien sin una importación estática de ellas. (2) Las importaciones estáticas de, por ejemplo, los métodos de clase JUnit Assert son claras como una campana. "ClaimTrue (...)" es tan legible como "Assert.assertTrue (...)", quizás más.
Alan Krueger el

55
Si tiene 5 importaciones estáticas en una clase de 500 líneas, es muy difícil saber de dónde provienen los métodos.
davetron5000

44
+1 para cuando desee que su código sea difícil de entender :)
Variable miserable

-5

Los uso cuando puedo. Tengo la configuración de IntelliJ para recordarme si lo olvido. Creo que se ve mucho más limpio que un nombre de paquete totalmente calificado.


13
Estás pensando en importaciones regulares. Las importaciones estáticas le permiten referirse a los miembros de una clase sin calificarlos con un nombre de clase, por ejemplo, la importación estática java.lang.system.out; out.println ("foo"); // en lugar de System.out.println ("foo");
sk.

Ahora bien, esta es una muy buena explicación de las importaciones estáticas ... lástima que no pueda un comentario 1
Eldelshell
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.