26 recomendaciones para usar el tipo var en Java


La Inferencia de tipo variable local de Java (LVTI) o, brevemente, el tipo var (el identificador var no es una palabra clave, sino un nombre de tipo reservado) se agregó a Java 10 usando JEP 286: Inferencia de tipo variable local . Al ser una función de compilación del 100%, no afecta el código de bytes, el tiempo de ejecución o el rendimiento. Básicamente, el compilador verifica el lado derecho del operador de asignación y, en base a él, determina el tipo específico de la variable y luego lo reemplaza con var .


Adem√°s, es √ļtil para reducir la verbosidad del c√≥digo repetitivo, y tambi√©n acelera el proceso de programaci√≥n en s√≠. Por ejemplo, es muy conveniente escribir var evenAndOdd =... lugar de Map<Boolean, List<Integer>> evenAndOdd =...


La aparición de var no significa que siempre sea conveniente usarlo en todas partes, a veces será más práctico hacerlo con herramientas estándar.


En este artículo, veremos 26 situaciones, con ejemplos de cuándo puede usar var y cuándo no vale la pena.


Punto 1: intente dar nombres significativos a las variables locales


Por lo general, nos enfocamos en dar los nombres correctos a los campos de las clases, pero no prestamos la misma atención a los nombres de las variables locales. Cuando nuestros métodos se implementan perfectamente, contienen poco código y tienen buenos nombres, muy a menudo no prestamos atención a las variables locales, ni siquiera reducimos por completo sus nombres.


Cuando usamos var en lugar de escribir tipos explícitos, el compilador los detecta automáticamente y sustituye var . Pero, por otro lado, como resultado de esto, se hace más difícil para las personas leer y comprender el código, ya que el uso de var puede complicar su legibilidad y comprensión. En la mayoría de los casos, esto se debe a que tendemos a ver el tipo de una variable como información primaria y su nombre como secundario. Aunque debería ser todo lo contrario.


Ejemplo 1:


Muchos probablemente estar√°n de acuerdo en que en el siguiente ejemplo, los nombres de las variables locales son demasiado cortos:


 // HAVING public boolean callDocumentationTask() { DocumentationTool dtl = ToolProvider.getSystemDocumentationTool(); DocumentationTask dtt = dtl.getTask(...); return dtt.call(); } 

Cuando se usan nombres cortos, junto con var , el c√≥digo se vuelve a√ļn menos claro:


 // AVOID public boolean callDocumentationTask() { var dtl = ToolProvider.getSystemDocumentationTool(); var dtt = dtl.getTask(...); return dtt.call(); } 

Opción más preferida:


 // PREFER public boolean callDocumentationTask() { var documentationTool = ToolProvider.getSystemDocumentationTool(); var documentationTask = documentationTool.getTask(...); return documentationTask.call(); } 

Ejemplo 2


Evite nombrar variables como esta:


 // AVOID public List<Product> fetchProducts(long userId) { var u = userRepository.findById(userId); var p = u.getCart(); return p; } 

Use nombres m√°s significativos:


 // PREFER public List<Product> fetchProducts(long userId) { var user = userRepository.findById(userId); var productList = user.getCart(); return productList; } 

Ejemplo 3


En un esfuerzo por dar nombres m√°s comprensibles a las variables locales, no vaya a extremos:


 // AVOID var byteArrayOutputStream = new ByteArrayOutputStream(); 

En cambio, puede usar una opción más corta, pero no menos comprensible:


 // PREFER var outputStream = new ByteArrayOutputStream(); // or var outputStreamOfFoo = new ByteArrayOutputStream(); 

¬ŅSab√≠a que Java tiene una clase interna llamada:
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState


Bueno, nombrar variables con este tipo puede ser complicado :)


Punto 2: use literales para ayudar a var a determinar el tipo de primitivo (int, long, float, double)


Sin el uso de literales para tipos primitivos, podemos encontrar que los tipos esperados e implícitos pueden diferir. Esto es causado por la conversión de tipo implícita utilizada por las variables var .


Por ejemplo, los siguientes dos fragmentos de código se comportan como se esperaba. Aquí declaramos explícitamente los tipos booleano y char :


 boolean flag = true; // this is of type boolean char a = 'a'; // this is of type char 

Ahora usamos var , en lugar de declarar explícitamente los tipos:


 var flag = true; // this is inferred as boolean var a = 'a'; // this is inferred as char 

Hasta ahora todo bien. Ahora haga lo mismo para los tipos int , long , float y double :


 int intNumber = 20; // this is of type int long longNumber = 20; // this is of type long float floatNumber = 20; // this is of type float, 20.0 double doubleNumber = 20; // this is of type double, 20.0 

Aunque el fragmento de código anterior es simple y directo, ahora usemos var en lugar de especificar explícitamente los tipos.


Evitar


 // AVOID var intNumber = 20; // this is inferred as int var longNumber = 20; // this is inferred as int var floatNumber = 20; // this is inferred as int var doubleNumber = 20; // this is inferred as int 

Las cuatro variables se mostrar√°n como int . Para corregir este comportamiento, necesitamos usar literales Java:


 // PREFER var intNumber = 20; // this is inferred as int var longNumber = 20L; // this is inferred as long var floatNumber = 20F; // this is inferred as float, 20.0 var doubleNumber = 20D; // this is inferred as double, 20.0 

Pero, ¬Ņqu√© sucede si declaramos un n√ļmero decimal?


Evite esto si espera obtener una variable de tipo float :


 // AVOID, IF THIS IS A FLOAT var floatNumber = 20.5; // this is inferred as double 

Para evitar sorpresas, use el literal apropiado:


 // PREFER, IF THIS IS A FLOAT var floatNumber = 20.5F; // this is inferred as float 

Punto 3: en algunos casos, las conversiones de tipo var e implícito pueden simplificar el soporte de código


Por ejemplo, supongamos que nuestro código está entre dos métodos. Un método obtiene un carrito de compras con diferentes productos y calcula el mejor precio. Para hacer esto, compara varios precios en el mercado y devuelve el precio total en forma de tipo flotante . Otro método simplemente deduce este precio de la tarjeta.


Primero, veamos un método que calcula el mejor precio:


 public float computeBestPrice(String[] items) { ... float price = ...; return price; } 

En segundo lugar, echemos un vistazo al método que funciona con el mapa:


 public boolean debitCard(float amount, ...) { ... } 

Ahora ponemos nuestro código entre estos dos métodos de servicio externo como cliente. Nuestros usuarios pueden elegir los productos para comprar, y calculamos el mejor precio para ellos, y luego cancelamos los fondos de la tarjeta:


 // AVOID public void purchaseCart(long customerId) { ... float price = computeBestPrice(...); debitCard(price, ...); } 

Despu√©s de un tiempo, la compa√Ī√≠a propietaria de la API decide abandonar la representaci√≥n material de los precios a favor del decimal (en lugar de flotante , ahora se usa int ). Entonces, modificaron el c√≥digo API de la siguiente manera:


 public int computeBestPrice(String[] items) { ... float realprice = ...; ... int price = (int) realprice; return price; } public boolean debitCard(int amount, ...) { ... } 

El hecho es que nuestro código usa una declaración explícita de una variable flotante como precio. En su forma actual, recibiremos un error en el momento de la compilación. Pero si hubiéramos previsto tal situación y hubiéramos utilizado var en lugar de flotante , nuestro código continuaría funcionando sin problemas, gracias a la conversión de tipo implícita:


 // PREFER public void purchaseCart(long customerId) { ... var price = computeBestPrice(...); debitCard(price, ...); } 

Punto 4: cuando los literales no son una solución adecuada, use una conversión explícita o descarte var


Algunos tipos primitivos en Java no tienen literales especiales, por ejemplo, byte y tipos cortos . En este caso, usando la designaci√≥n de tipo expl√≠cito, podemos crear variables sin ning√ļn problema.


Use esto en lugar de var :


 // PREFER THIS INSTEAD OF USING VAR byte byteNumber = 45; // this is of type byte short shortNumber = 4533; // this is of type short 

Pero, ¬Ņpor qu√© en esta situaci√≥n da preferencia a la notaci√≥n de tipo expl√≠cito en lugar de simplemente usar var ? Bueno, escribamos este c√≥digo usando var . Tenga en cuenta que en ambos casos, el compilador asumir√° que necesita variables de tipo int .


Evita este error:


 // AVOID var byteNumber = 45; // this is inferred as int var shortNumber = 4533; // this is inferred as int 

Aquí no hay literales que nos ayuden, por lo tanto, nos vemos obligados a utilizar la conversión explícita de tipo descendente. Personalmente, evitaré tales situaciones, porque no veo ninguna ventaja aquí.


Solo use esta entrada si realmente quiere usar var :


 // PREFER THIS ONLY IF YOU WANT TO USE VAR var byteNumber = (byte) 45; // this is inferred as byte var shortNumber = (short) 4533; // this is inferred as short 

Punto 5: evite usar var si los nombres de las variables no contienen suficiente información de tipo para comprender el código


La ventaja de usar var es escribir código más conciso. Por ejemplo, en el caso de usar constructores, podemos evitar la necesidad de repetir el nombre de la clase y, por lo tanto, eliminar la redundancia de código.


Evita lo siguiente:


 // AVOID MemoryCacheImageInputStream inputStream = new MemoryCacheImageInputStream(...); 

Use en su lugar:


 // PREFER var inputStream = new MemoryCacheImageInputStream(...); 

Para la construcción a continuación, var también será una buena manera de simplificar el código sin perder información.


Evitar


 // AVOID JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); StandardJavaFileManager fm = compiler.getStandardFileManager(...); 

Utiliza el siguiente código:


 // PREFER var compiler = ToolProvider.getSystemJavaCompiler(); var fileManager = compiler.getStandardFileManager(...); 

Entonces, ¬Ņpor qu√© nos sentimos m√°s c√≥modos trabajando con var en los ejemplos presentados? Porque toda la informaci√≥n necesaria est√° contenida en los nombres de las variables. Pero si var , en combinaci√≥n con un nombre de variable, reduce la claridad del c√≥digo, es mejor negarse a usarlo.


Evitar


 // AVOID public File fetchCartContent() { return new File(...); } // As a human, is hard to infer the "cart" type without // inspecting the fetchCartContent() method var cart = fetchCartContent(); 

Uso:


 // PREFER public File fetchCartContent() { return new File(...); } File cart = fetchCartContent(); 

Considere, por ejemplo, el uso de la clase java.nio.channels.Selector . Esta clase tiene un método estático open() que devuelve un nuevo selector y lo abre. Pero aquí puede pensar fácilmente que el método Selector.open() puede devolver un tipo booleano , dependiendo del éxito de abrir un selector existente, o incluso devolver un vacío . El uso de var aquí conducirá a la pérdida de información y la confusión en el código.


Punto 6: el tipo var garantiza la seguridad en tiempo de compilación


Esto significa que no podemos compilar una aplicación que intente realizar asignaciones incorrectas. Por ejemplo, el siguiente código no se compila:


 // IT DOESN'T COMPILE var items = 10; items = "10 items"; // incompatible types: String cannot be converted to int 

Pero este compila:


 var items = 10; items = 20; 

Y este código compila con éxito:


 var items = "10"; items = "10 items"; 

Una vez que el compilador ha definido el valor de la variable var , no podemos asignar nada m√°s que este tipo.


Punto 7: var no se puede usar para crear instancias de un tipo específico y asignarlo a una variable de tipo de interfaz


En Java, utilizamos el enfoque de "programación con interfaces". Por ejemplo, creamos una instancia de la clase ArrayList, asociándola con una abstracción (interfaz):


 List<String> products = new ArrayList<>(); 

Y evitamos cosas como vincular un objeto a una variable del mismo tipo:


 ArrayList<String> products = new ArrayList<>(); 

Esta es la pr√°ctica m√°s com√ļn y deseable, ya que podemos reemplazar f√°cilmente la implementaci√≥n de la interfaz con cualquier otra. Para esto, solo es necesario declarar una variable de tipo de interfaz.


No podremos seguir este concepto usando variables var, como siempre se muestra un tipo específico para ellos. Por ejemplo, en el siguiente fragmento de código, el compilador determinará el tipo de la variable como ArrayList<String> :


 var productList = new ArrayList<String>(); // inferred as ArrayList<String> 

Hay varios argumentos de defensa que explican este comportamiento:


  • var se usa para variables locales, donde, en la mayor√≠a de los casos, la programaci√≥n usando interfaces se usa menos que en los casos con par√°metros de m√©todo devueltos por valores o campos


  • El alcance de las variables locales debe ser peque√Īo, por lo que resolver los problemas causados ‚Äč‚Äčpor cambiar a otra implementaci√≥n no deber√≠a ser muy dif√≠cil.


  • var trata el c√≥digo de la derecha como el inicializador utilizado para determinar el tipo real. Si, en alg√ļn momento, se cambia el inicializador, entonces el tipo que se est√° definiendo tambi√©n puede cambiar, causando problemas en el c√≥digo que se basa en esta variable.



Párrafo 8: la probabilidad de la conclusión de un tipo inesperado


El uso de var en combinación con un operador de diamante (<>) en ausencia de información para identificar el tipo puede conducir a resultados inesperados.


Antes de Java 7, se usaba la inferencia de tipo explícita para las colecciones:


 // explicitly specifying generic class's instantiation parameter type List<String> products = new ArrayList<String>(); 

Comenzando con Java 7, se introdujo el operador de diamantes . En este caso, el compilador derivar√° independientemente el tipo necesario:


 // inferring generic class's instantiation parameter type List<String> products = new ArrayList<>(); 

¬ŅQu√© tipo se mostrar√° en el siguiente c√≥digo?


Debe evitar tales construcciones:


 // AVOID var productList = new ArrayList<>(); // is inferred as ArrayList<Object> 

El tipo se definirá como ArrayList<Object> . Esto se debe a que no se proporciona la información necesaria para determinar correctamente el tipo. Esto lleva al hecho de que se seleccionará el tipo más cercano, que puede ser compatible con el contexto de lo que está sucediendo. En este caso, Object .


Por lo tanto, var solo se puede usar si proporcionamos la información necesaria para determinar el tipo esperado. El tipo se puede especificar directamente o pasar como argumento.


Especifique directamente el tipo:


 // PREFER var productList = new ArrayList<String>(); // inferred as ArrayList<String> 

Pase argumentos del tipo requerido:


 var productStack = new ArrayDeque<String>(); var productList = new ArrayList<>(productStack); // inferred as ArrayList<String> 

 Product p1 = new Product(); Product p2 = new Product(); var listOfProduct = List.of(p1, p2); // inferred as List<Product> // DON'T DO THIS var listofProduct = List.of(); // inferred as List<Object> listofProduct.add(p1); listofProduct.add(p2); 

Elemento 9: asignar una matriz a una variable var no requiere corchetes []


Todos sabemos cómo declarar matrices en Java:


 int[] numbers = new int[5]; // or, less preferred int numbers[] = new int[5]; 

¬ŅQu√© tal usar var cuando se trabaja con matrices? En este caso, no es necesario usar soportes en el lado izquierdo.


Evite lo siguiente (esto ni siquiera se compila):


 // IT DOESN'T COMPILE var[] numbers = new int[5]; // or var numbers[] = new int[5]; 

Uso:


 // PREFER var numbers = new int[5]; // inferred as array of int numbers[0] = 2; // work numbers[0] = 2.2; // doesn't work numbers[0] = "2"; // doesn't work 

El siguiente código usando var también falla al compilar. Esto se debe a que el compilador no puede determinar el tipo desde el lado derecho:


 // explicit type work as expected int[] numbers = {1, 2, 3}; // IT DOESN'T COMPILE var numbers = {1, 2, 3}; var numbers[] = {1, 2, 3}; var[] numbers = {1, 2, 3}; 

Elemento 10: var no se puede usar al declarar m√ļltiples variables en la misma l√≠nea


Si desea declarar variables del mismo tipo a la vez, debe saber que var no es adecuado para esto. El siguiente código no se compila:


 // IT DOESN'T COMPILE // error: 'var' is not allowed in a compound declaration var hello = "hello", bye = "bye", welcome = "welcome"; 

Use en su lugar:


 // PREFER String hello = "hello", bye = "bye", welcome = "welcome"; 

O es:


 // PREFER var hello = "hello"; var bye = "bye"; var welcome = "welcome"; 

Punto 11: las variables locales deben esforzarse por minimizar su alcance. El tipo var refuerza esta afirmación.


Mantenga un peque√Īo alcance para las variables locales: estoy seguro de que escuch√≥ esta declaraci√≥n antes de la var .


La legibilidad y la corrección rápida de errores son argumentos a favor de este enfoque. Por ejemplo, definamos una pila de la siguiente manera:


Evita esto:


 // AVOID ... var stack = new Stack<String>(); stack.push("George"); stack.push("Tyllen"); stack.push("Martin"); stack.push("Kelly"); ... // 50 lines of code that doesn't use stack // George, Tyllen, Martin, Kelly stack.forEach(...); ... 

Tenga en cuenta que estamos llamando al método forEach() , que se hereda de java.util.Vector . Este método pasará por la pila como cualquier otro vector y esto es lo que necesitamos. Pero ahora decidimos usar ArrayDeque lugar de Stack . Cuando hacemos esto, el método forEach() recibirá una implementación de ArrayDeque que atravesará la pila como una pila estándar (LIFO)


 // AVOID ... var stack = new ArrayDeque<String>(); stack.push("George"); stack.push("Tyllen"); stack.push("Martin"); stack.push("Kelly"); ... // 50 lines of code that doesn't use stack // Kelly, Martin, Tyllen, George stack.forEach(...); ... 

Esto no es lo que queremos. Es demasiado dif√≠cil rastrear el error aqu√≠, porque el c√≥digo que contiene la parte forEach() no se encuentra al lado del c√≥digo en el que se realizaron los cambios. Para aumentar la velocidad de b√ļsqueda y correcci√≥n de errores, es mucho mejor escribir c√≥digo usando la variable stack , lo m√°s cerca posible de la declaraci√≥n de esta variable.


Esto se hace mejor de la siguiente manera:


 // PREFER ... var stack = new Stack<String>(); stack.push("George"); stack.push("Tyllen"); stack.push("Martin"); stack.push("Kelly"); ... // George, Tyllen, Martin, Kelly stack.forEach(...); ... // 50 lines of code that doesn't use stack 

Ahora, cuando el desarrollador cambie de Stack a ArrayQueue , podr√° notar r√°pidamente el error y solucionarlo.


Cl√°usula 12: el tipo var simplifica el uso de varios tipos en operadores ternarios


Podemos usar diferentes tipos de operandos en el lado derecho del operador ternario.


Al especificar explícitamente los tipos, el siguiente código no se compila:


 // IT DOESN'T COMPILE List code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); // or Set code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); 

Sin embargo, podemos hacer esto:


 Collection code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); Object code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); 

El siguiente código tampoco se compila:


 // IT DOESN'T COMPILE int code = intOrString ? 12112 : "12112"; String code = intOrString ? 12112 : "12112"; 

Pero puedes usar tipos m√°s generales:


 Serializable code = intOrString ? 12112 : "12112"; Object code = intOrString ? 12112 : "12112"; 

En todos estos casos, es mejor preferir var :


 // PREFER // inferred as Collection<Integer> var code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); // inferred as Serializable var code = intOrString ? 12112 : "12112"; 

De estos ejemplos no se deduce que el tipo var define tipos de objetos en tiempo de ejecución. ¡Esto no es así!


Y, por supuesto, el tipo var funcionar√° correctamente con los mismos tipos de ambos operandos:


 // inferred as float var code = oneOrTwoDigits ? 1211.2f : 1211.25f; 

Punto 13: el tipo var se puede usar dentro de los bucles


Podemos reemplazar fácilmente la declaración explícita de tipos en bucles for con el tipo var .


Cambiar un tipo int explícito a var :


 // explicit type for (int i = 0; i < 5; i++) { ... } // using var for (var i = 0; i < 5; i++) { // i is inferred of type int ... } 

Cambiar el tipo explícito de Order a var :


 List<Order> orderList = ...; // explicit type for (Order order : orderList) { ... } // using var for (var order : orderList) { // order type is inferred as Order ... } 

Punto 14: var funciona bien con flujos en Java 8


Es muy simple usar var de Java 10 con secuencias que aparecieron en Java 8.


Simplemente puede reemplazar la declaración explícita de tipo Stream con var :


Ejemplo 1:


 // explicit type Stream<Integer> numbers = Stream.of(1, 2, 3, 4, 5); numbers.filter(t -> t % 2 == 0).forEach(System.out::println); // using var var numbers = Stream.of(1, 2, 3, 4, 5); // inferred as Stream<Integer> numbers.filter(t -> t % 2 == 0).forEach(System.out::println); 

Ejemplo 2


 // explicit types Stream<String> paths = Files.lines(Path.of("...")); List<File> files = paths.map(p -> new File(p)).collect(toList()); // using var var paths = Files.lines(Path.of("...")); // inferred as Stream<String> var files = paths.map(p -> new File(p)).collect(toList()); // inferred as List<File> 

Cl√°usula 15: var se puede usar al declarar variables locales destinadas a dividir grandes cadenas de expresiones en partes


Las expresiones con una gran cantidad de anidamiento se ven impresionantes y generalmente parecen alg√ļn tipo de c√≥digo inteligente e importante. En el caso de que sea necesario facilitar la legibilidad del c√≥digo, se recomienda dividir una expresi√≥n grande utilizando variables locales. Pero a veces escribir muchas variables locales parece un trabajo muy agotador que me gustar√≠a evitar.


Un ejemplo de una gran expresión:


 List<Integer> intList = List.of(1, 1, 2, 3, 4, 4, 6, 2, 1, 5, 4, 5); // AVOID int result = intList.stream() .collect(Collectors.partitioningBy(i -> i % 2 == 0)) .values() .stream() .max(Comparator.comparing(List::size)) .orElse(Collections.emptyList()) .stream() .mapToInt(Integer::intValue) .sum(); 

Es mejor dividir el código en sus componentes:


 List<Integer> intList = List.of(1, 1, 2, 3, 4, 4, 6, 2, 1, 5, 4, 5); // PREFER Map<Boolean, List<Integer>> evenAndOdd = intList.stream() .collect(Collectors.partitioningBy(i -> i % 2 == 0)); Optional<List<Integer>> evenOrOdd = evenAndOdd.values() .stream() .max(Comparator.comparing(List::size)); int sumEvenOrOdd = evenOrOdd.orElse(Collections.emptyList()) .stream() .mapToInt(Integer::intValue) .sum(); 

La segunda versión del código parece más legible y simple, pero la primera versión también tiene derecho a existir. Es absolutamente normal que nuestra mente se adapte a la comprensión de expresiones tan grandes y las prefiera a las variables locales. Sin embargo, usar el tipo var puede ayudar a dividir estructuras grandes al reducir el esfuerzo para declarar variables locales:


 var intList = List.of(1, 1, 2, 3, 4, 4, 6, 2, 1, 5, 4, 5); // PREFER var evenAndOdd = intList.stream() .collect(Collectors.partitioningBy(i -> i % 2 == 0)); var evenOrOdd = evenAndOdd.values() .stream() .max(Comparator.comparing(List::size)); var sumEvenOrOdd = evenOrOdd.orElse(Collections.emptyList()) .stream() .mapToInt(Integer::intValue) .sum(); 

Cláusula 16: var no se puede usar como un tipo de retorno o como un tipo de argumento de método


Los dos fragmentos de código que se muestran a continuación no se compilarán.


Usando var como el tipo de retorno:


 // IT DOESN'T COMPILE public var countItems(Order order, long timestamp) { ... } 

Usando var como un tipo de argumento de método:


 // IT DOESN'T COMPILE public int countItems(var order, var timestamp) { ... } 

Cláusula 17: las variables locales de tipo var pueden pasarse como parámetros de un método o pueden tomar un valor de retorno


Los siguientes fragmentos de código se compilarán y funcionarán correctamente:


 public int countItems(Order order, long timestamp) { ... } public boolean checkOrder() { var order = ...; // an Order instance var timestamp = ...; // a long representing a timestamp var itemsNr = countItems(order, timestamp); // inferred as int type ... } 

:


 public <A, B> B contains(A container, B tocontain) { ... } var order = ...; // Order instance var product = ...; // Product instance var resultProduct = contains(order, product); // inferred as Product type 

18: var


:


 public interface Weighter { int getWeight(Product product); } // AVOID Weighter weighter = new Weighter() { @Override public int getWeight(Product product) { ... } }; Product product = ...; // a Product instance int weight = weighter.getWeight(product); 

var :


 public interface Weighter { int getWeight(Product product); } // PREFER var weighter = new Weighter() { @Override public int getWeight(Product product) { ... } }; var product = ...; // a Product instance var weight = weighter.getWeight(product); 

19: var effectively final


, :


… Java SE 8, , final effectively final. , , effectively final .

, var effectively final. .


:


 public interface Weighter { int getWeight(Product product); } // AVOID int ratio = 5; // this is effectively final Weighter weighter = new Weighter() { @Override public int getWeight(Product product) { return ratio * ...; } }; ratio = 3; // this reassignment will cause error 

:


 public interface Weighter { int getWeight(Product product); } // PREFER var ratio = 5; // this is effectively final var weighter = new Weighter() { @Override public int getWeight(Product product) { return ratio * ...; } }; ratio = 3; // this reassignment will cause error 

20: var- final-


var ( , effectively final). , final .


:


 // AVOID // IT DOESN'T COMPILE public void discount(int price) { final int limit = 2000; final int discount = 5; if (price > limit) { discount++; // this reassignment will cause error, which is ok } } 

:


 // PREFER // IT DOESN'T COMPILE public void discount(int price) { final var limit = 2000; final var discount = 5; if (price > limit) { discount++; // this reassignment will cause error, which is ok } } 

21:


var , . , var , :


 // IT DOESN'T COMPILE // lambda expression needs an explicit target-type var f = x -> x + 1; // method reference needs an explicit target-type var exception = IllegalArgumentException::new; 

:


 // PREFER Function<Integer, Integer> f = x -> x + 1; Supplier<IllegalArgumentException> exception = IllegalArgumentException::new; 

Java 11 var - . Java 11:


 // Java 11 (var x, var y) -> x + y // or (@Nonnull var x, @Nonnull var y) -> x + y 

22: var null'


var - .


( null ):


 // IT DOESN'T COMPILE var message = null; // result in an error of type: variable initializer is 'null' 

( ):


 // IT DOESN'T COMPILE var message; // result in: cannot use 'var' on variable without initializer ... message = "hello"; 

:


 // PREFER String message = null; // or String message; ... message = "hello"; 

23: var


var , .


:


 // IT DOESN'T COMPILE public class Product { private var price; // error: 'var' is not allowed here private var name; // error: 'var' is not allowed here ... } 

:


 // PREFER public class Product { private int price; private String name; ... } 

24: var catch


, try-with-resources


catch


, , .


:


 // IT DOESN'T COMPILE try { TimeUnit.NANOSECONDS.sleep(5000); } catch (var ex) { ... } 

:


 // PREFER try { TimeUnit.NANOSECONDS.sleep(5000); } catch (InterruptedException ex) { ... } 

Try-with-resources


, var try-with-resources .


, :


 // explicit type try (PrintWriter writer = new PrintWriter(new File("welcome.txt"))) { writer.println("Welcome message"); } 

var :


 // using var try (var writer = new PrintWriter(new File("welcome.txt"))) { writer.println("Welcome message"); } 

25: var


, :


 public <T extends Number> T add(T t) { T temp = t; ... return temp; } 

, var , T var :


 public <T extends Number> T add(T t) { var temp = t; ... return temp; } 

, var :


 codepublic <T extends Number> T add(T t) { List<T> numbers = new ArrayList<>(); numbers.add((T) Integer.valueOf(3)); numbers.add((T) Double.valueOf(3.9)); numbers.add(t); numbers.add("5"); // error: incompatible types: String cannot be converted to T ... } 

List<T> var :


 public <T extends Number> T add(T t) { var numbers = new ArrayList<T>(); // DON'T DO THIS, DON'T FORGET THE, T var numbers = new ArrayList<>(); numbers.add((T) Integer.valueOf(3)); numbers.add((T) Double.valueOf(3.9)); numbers.add(t); numbers.add("5"); // error: incompatible types: String cannot be converted to T ... } 

26: var Wildcards (?),


? Wildcards


var :


 // explicit type Class<?> clazz = Integer.class; // use var var clazz = Integer.class; 

Foo<?> var , , var .


, , , , . , ArrayList , Collection<?> :


 // explicit type Collection<?> stuff = new ArrayList<>(); stuff.add("hello"); // compile time error stuff.add("world"); // compile time error // use var, this will remove the error, but I don't think that this is // what you had in mind when you wrote the above code var stuff = new ArrayList<>(); strings.add("hello"); // no error strings.add("world"); // no error 

(Foo <? extends T>) (Foo <? super T>)


, :


 // explicit type Class<? extends Number> intNumber = Integer.class; Class<? super FilterReader> fileReader = Reader.class; 

, , :


 // IT DOESN'T COMPILE // error: Class<Reader> cannot be converted to Class<? extends Number> Class<? extends Number> intNumber = Reader.class; // error: Class<Integer> cannot be converted to Class<? super FilterReader> Class<? super FilterReader> fileReader = Integer.class; 

var :


 // using var var intNumber = Integer.class; var fileReader = Reader.class; 

, . ‚Äď :


 // this will compile just fine var intNumber = Reader.class; var fileReader = Integer.class; 

Conclusión


¬ę var ¬Ľ, Java 10. , . , var , .


var Java!

Source: https://habr.com/ru/post/438206/


All Articles