descargar - java offline
Java: Fuera con lo viejo, con lo nuevo (30)
Anotaciones
Me pregunto si nadie lo mencionó hasta ahora, pero muchos marcos se basan en anotaciones, por ejemplo, Spring e Hibernate. Hoy es común descartar que los archivos de configuración xml estén a favor de las anotaciones en el código (aunque esto significa perder flexibilidad al pasar de la configuración al metacódigo, pero a menudo es la elección correcta). El mejor ejemplo es EJB 2 (y anterior) comparado a EJB 3.0 y cómo la programación de EJB se ha simplificado gracias a las anotaciones.
Las anotaciones también me parecen muy útiles en combinación con algunas herramientas de AOP como AspectJ o Spring AOP. Tal combinación puede ser muy poderosa.
Java se acerca a la versión 7. Se me ocurre que debe haber muchos libros de texto y manuales de capacitación que enseñen métodos basados en versiones anteriores de Java, donde los métodos enseñados tendrían ahora mejores soluciones.
¿Cuáles son algunas situaciones de código repetitivo, especialmente las que ves que las personas implementan por la fuerza del hábito, que te encuentras refactorizando para utilizar las últimas versiones de Java?
Aquí hay uno que veo:
String.split() versus StringTokenizer .
StringTokenizer no se recomienda para código nuevo, pero todavía veo que la gente lo usa.
En cuanto a la compatibilidad, Sun hace un gran esfuerzo para que Java sea compatible con versiones anteriores y posteriores. Eso explica en parte por qué los genéricos son tan complejos. También se supone que la depreciación ayuda a facilitar las transiciones del código antiguo al nuevo.
Aunque admito que las importaciones estáticas pueden ser usadas en exceso, me gusta usar
import static Math.* ;
en clases que usan muchas funciones matemáticas. Realmente puede disminuir la verbosidad de tu código. Sin embargo, no lo recomendaría para bibliotecas menos conocidas, ya que eso puede generar confusión.
Cambiando las pruebas de estilo JUnit 3:
class Test extends TestCase {
public void testYadaYada() { ... }
}
para JUnit 4 pruebas de estilo:
class Test {
@Test public void yadaYada() { ... }
}
Comparaciones de cadenas, realmente los programadores de Java de la vieja escuela que conocí harían:
String s1 = "...", s2 = "...";
if (s1.intern() == s2.intern()) {
....
}
(Supuestamente por razones de rendimiento)
Mientras que en estos días la mayoría de la gente simplemente hace:
String s1 = "...", s2 = "...";
if (s1.equals(s2)) {
....
}
Conversión explícita entre los tipos de primitiva y de envoltura (por ejemplo, de entero a int o viceversa) que se trata automáticamente mediante autoboxing / unboxing desde Java 1.5.
Un ejemplo es
Integer myInteger = 6;
int myInt = myInteger.intValue();
Simplemente puede escribirse como
Integer myInteger = 6;
int myInt = myInteger;
Pero ten cuidado con NullPointerExceptions :)
Convertir clases para usar genéricos, evitando situaciones con lanzamientos innecesarios.
Convertir un número a una Cadena:
String s = n + "";
En este caso, creo que siempre ha habido una mejor manera de hacerlo:
String s = String.valueOf(n);
De acuerdo, ahora es mi turno de que me griten.
No recomiendo el 90% de estos cambios.
No es que no sea una buena idea usarlos con código nuevo, pero irrumpir en el código existente para cambiar un bucle for a un bucle for (:) es simplemente una pérdida de tiempo y la posibilidad de romper algo. (IIWDFWI) Si funciona, ¡no lo arregles!
Si se encuentra en una empresa de desarrollo real, ese cambio ahora se convierte en algo para revisar el código, probar y posiblemente depurar.
Si alguien que hace este tipo de refactor sin ningún motivo causara un problema de NINGÚN tipo, les daría un montón de mierda.
Por otro lado, si estás en el código y cambias cosas en esa línea de todos modos, no dudes en limpiarlo.
Además, todas las sugerencias en nombre de "Rendimiento" realmente necesitan aprender sobre las leyes de optimización. En dos palabras, ¡no! ¡Nunca! (Busque en Google las "Reglas de optimización si no me cree").
Enums. Reemplazando
public static final int CLUBS = 0;
public static final int DIAMONDS = 1;
public static final int HEARTS = 2;
public static final int SPADES = 3;
con
public enum Suit {
CLUBS,
DIAMONDS,
HEARTS,
SPADES
}
Estoy un poco receloso de refactorizar en esta línea si eso es todo lo que estás haciendo con tu árbol fuente. Los ejemplos hasta ahora no parecen ser razones solas para cambiar una base de código de trabajo, pero tal vez si está agregando nuevas funcionalidades, debería aprovechar todas las novedades.
Al final del día, estos ejemplos en realidad no están eliminando el código de la placa de la caldera , solo están usando las construcciones más manejables de los JDK más nuevos para hacer un código de placa de caldera agradable .
La mayoría de las formas de hacer que su código sea elegante no están en el JDK.
Genéricos y ya no es necesario crear un iterador para recorrer todos los elementos de una colección. La nueva versión es mucho mejor, más fácil de usar y más fácil de entender.
EDITAR:
Antes de:
List l = someList;
Iterator i = l.getIterator();
while (i.hasNext()) {
MyObject o = (MyObject)i.next();
}
Después
List<MyObject> l = someList;
for (MyObject o : l) {
//do something
}
La impresión formateada se introdujo tan tarde como en JDK 1.5. Entonces, en lugar de usar:
String str = "test " + intValue + " test " + doubleValue;
o el equivalente usando un StringBuilder,
uno puede usar
String str = String.format("test %d test %lg", intValue, doubleValue);
El último es mucho más legible, tanto de la concatenación de cadenas como de las versiones del generador de cadenas. Todavía encuentro que las personas adoptan este estilo muy lentamente. Log4j framework, por ejemplo, no usa esto, aunque creo que sería muy beneficioso hacerlo.
La nueva versión de Java rara vez rompe el código existente, así que simplemente deje el código anterior solo y concéntrese en cómo la nueva característica hace su vida más fácil.
Si solo dejas el código anterior solo, entonces escribir código nuevo usando nuevas características no es tan aterrador.
Las colecciones genéricas hacen que la codificación sea mucho más resistente a los insectos. ANTIGUO:
Vector stringVector = new Vector();
stringVector.add("hi");
stringVector.add(528); // oops!
stringVector.add(new Whatzit()); // Oh my, could spell trouble later on!
NUEVO:
ArrayList<String> stringList = new ArrayList<String>();
stringList.add("hello again");
stringList.add(new Whatzit()); // Won''t compile!
Lo nuevo for cada una de las construcciones para iterar sobre las matrices y la colección es lo más importante para mí.
En estos días, cada vez que veo el repetitivo for iteración iterar sobre una matriz uno por uno usando una variable de índice, me dan ganas de gritar:
// AGGHHH!!!
int[] array = new int[] {0, 1, 2, 3, 4};
for (int i = 0; i < array.length; i++)
{
// Do something...
}
Reemplazando lo anterior por el constructo introducido en Java 5 :
// Nice and clean.
int[] array = new int[] {0, 1, 2, 3, 4};
for (int n : array)
{
// Do something...
}
Limpio, conciso y, lo mejor de todo, da sentido al código en lugar de mostrar cómo hacer algo.
Claramente, el código tiene un significado para iterar sobre la colección, en lugar del antiguo ciclo for dice cómo iterar sobre una matriz.
Además, como cada elemento se procesa independientemente de otros elementos, puede permitir optimizaciones futuras para el procesamiento paralelo sin tener que realizar cambios en el código. (Solo especulación, por supuesto)
P1: Bueno, las situaciones más obvias se encuentran en las colecciones genéricas / tipo específicas. El otro que me viene inmediatamente a la mente es el bucle mejorado, que creo que es mucho más limpio y más fácil de entender.
P2: En general, he estado agrupando la JVM junto con mi aplicación para aplicaciones orientadas al cliente. Esto nos permite usar nuevas funciones de idioma sin tener que preocuparnos por la incompatibilidad de JVM.
Si no estuviera agrupando el JRE, probablemente me quedaría con el 1.4 por razones de compatibilidad.
Patrones de singleton mejorados. Técnicamente, estos están cubiertos por las enums de respuestas populares, pero es una subcategoría significativa.
public enum Singleton {
INSTANCE;
public void someMethod() {
...
}
}
es más limpio y más seguro que
public class Singleton {
public static final Singleton INSTANCE = new Singleton();
private Singleton() {
...
}
public void someMethod() {
...
}
}
Relacionado con varargs ; el método de utilidad Arrays.asList() que, a partir de Java 5, toma parámetros varargs es inmensamente útil.
A menudo me encuentro simplificando algo así como
List<String> items = new ArrayList<String>();
items.add("one");
items.add("two");
items.add("three");
handleItems(items);
mediante el uso
handleItems(Arrays.asList("one", "two", "three"));
Un cambio simple desde 1.5, pero hace una pequeña diferencia: en la API de Swing accediendo al panel de contenido de un JFrame:
myframe.getContentPane().add(mycomponent);
se convierte
myframe.add(mycomponent);
Y, por supuesto, la introducción de Enums ha cambiado la forma en que se comportan muchas aplicaciones que usaron constantes en el pasado.
String.format () ha mejorado enormemente la manipulación de cadenas y la declaración ternaria if es bastante útil para facilitar la lectura del código.
Usando Iterator:
List list = getTheList();
Iterator iter = list.iterator()
while (iter.hasNext()) {
String s = (String) iter.next();
// .. do something
}
O una forma alternativa a veces vista:
List list = getTheList();
for (Iterator iter = list.iterator(); iter.hasNext();) {
String s = (String) iter.next();
// .. do something
}
Ahora todo se reemplaza por:
List<String> list = getTheList();
for (String s : list) {
// .. do something
}
Usando el nuevo DefaultRowSorter de DefaultRowSorter para ordenar tablas en lugar de DefaultRowSorter desde cero.
Usar Vector en lugar de las nuevas Colecciones.
Usar clases en lugar de enumeraciones
public class Enum
{
public static final Enum FOO = new Enum();
public static final Enum BAR = new Enum();
}
Usar Thread en lugar del nuevo paquete java.util.concurrency.
Usar variables locales de tipo StringBuffer para realizar la concatenación de cadenas. A menos que se requiera sincronización, ahora se recomienda usar StringBuilder lugar, porque esta clase ofrece un mejor rendimiento (presumiblemente porque no está sincronizado).
Usar variables locales de tipo Vector para contener una lista de objetos. A menos que se requiera sincronización, ahora se recomienda utilizar una implementación de List como ArrayList, porque esta clase ofrece un mejor rendimiento (porque no está sincronizada).
VARARGS puede ser útil también.
Por ejemplo, puedes usar:
public int add(int... numbers){
int sum = 0 ;
for (int i : numbers){
sum+=i;
}
return sum ;
}
en lugar de:
public int add(int n1, int n2, int n3, int n4) ;
o
public int add(List<Integer> numbers) ;
Vale la pena señalar que Java 5.0 ha estado fuera durante cinco años y solo ha habido cambios menores desde entonces. Tendría que estar trabajando en un código muy antiguo para seguir refabrándolo.
copiando una matriz existente a una nueva matriz:
pre-Java 5 :
int[] src = new int[] {1, 2, 3, 4, 5};
int[] dest = new int[src.length];
System.arraycopy(src, 0, dest, 0, src.length);
Java 6 :
int[] src = new int[] {1, 2, 3, 4, 5};
int[] dest = Arrays.copyOf(src, src.length);
anteriormente, tuve que crear explícitamente una nueva matriz y luego copiar los elementos fuente a la nueva matriz (llamando a un método con muchos parámetros). ahora, la sintaxis es más limpia y la nueva matriz es devuelta por un método, no tengo que crearla. por cierto, el método Arrays.copyOf tiene una variación llamada Arrays.copyOfRange , que copia una región específica de la matriz de origen (más o menos como System.arraycopy ).
leyendo una cadena de entrada estándar:
Java pre-5 :
try {
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
String str = reader.readLine();
reader.close();
}
catch (IOException e) {
System.err.println("error when closing input stream.");
}
Java 5 :
Scanner reader = new Scanner(System.in);
String str = reader.nextLine();
reader.close();
Java 6 :
Console reader = System.console();
String str = reader.readLine();