www.it-ebooks.info
Elogios para la Primera Edición "Claro que quisiera tener este libro hace diez años. Algunos podrían pensar que yo no necesito ningún libro de Java, pero necesito esta. " -James Gosling, colega y vicepresidente de Sun Microsystems, Inc., y inventor del lenguaje de programación Java
"Un excelente libro, repleto de buenos consejos sobre cómo utilizar el programa de Javaidioma ming y la programación orientada a objetos en general. " -Gilad Bracha, distinguido ingeniero, Cadence Design Systems, y coautor de El Java ™ Especificación del lenguaje, Tercera Edición (Addison-Wesley, 2005)
"10/10-anyone aspiran a escribir buen código Java que otros apreciarán la lectura y el mantenimiento deben estar obligados a poseer una copia de este libro. Este es uno de esos libros raros en los que la información no se volverá obsoleto con las versiones posteriores de la biblioteca JDK ". -Peter Tran, camarero, JavaRanch.com
"El mejor libro que se haya escrito en Java .... Realmente genial; muy legible y eminentemente útil. No puedo decir suficientes cosas buenas sobre este libro. En JavaOne 2001, James Gosling dijo: 'Ve a comprar este libro! "Me alegro de haberlo hecho, y yo no podía estar de acuerdo más ". -Keith Edwards, miembro de alto rango del personal de investigación, Computer Science Lab en el Centro de Investigación de Palo Alto (PARC), y autor de Core JINI (Prentice Hall, 2000)
"Este es un verdaderamente excelente libro hecho por el hombre que diseñó varios de los mejores APIs de la plataforma Java recientes (incluyendo el API Collections). " -James Clark, director técnico del Grupo de Trabajo XML durante la creación de la Recomendación XML 1.0; editor de los XPath y XSLT Recomendaciones
www.it-ebooks.info
"Gran contenido. Análogo al clásico de Scott Meyers Efectiva de C + +. Si conoces los conceptos básicos de Java, este tiene que ser su próximo libro ". -Gary K. Evans, OO mentor y consultor, Evanetics, Inc.
"Josh Bloch da una gran comprensión de las mejores prácticas que en realidad sólo pueden ser descuEred después de años de estudio y experiencia. " -Mark Mascolino, ingeniero de software
"Este es un libro extraordinario. Cubre con claridad muchas de las sutilezas lenguaje / plataforma y el engaño que necesita para aprender a convertirse en un verdadero maestro de Java ". -Victor Wiewiorowski, desarrollo vicepresidente y gerente de calidad de código, ValueCommerce Co., Tokio, Japón
"Me gustan los libros que prometer menos en sus títulos y el exceso de entregar en sus contenidos. Este libro consta de 57 artículos de consejos de programación que están bien elegidos. Cada ítem revela un claro y profundo conocimiento de la lengua,. Cada uno ilustra en estilo sencillo y práctico términos de los límites de la programación de la intuición por sí sola, o tomar el camino más directo a una solución sin entender completamente lo que ofrece el lenguaje ". -Michael Ernest, Inkling Research, Inc.
"Yo no encuentro muchos libros de programación que me hacen querer leer cada páginaeste es uno de ellos. " -Matt Tucker, director técnico, Jive Software
"Gran how-to de recursos para el desarrollador experimentado." -John Zukowski, autor de numerosos libros de Java
"Elegí este libro hasta hace dos semanas y puedo decir con seguridad que aprendí más sobre la Lenguaje Java en tres días de la lectura de lo que hice en tres meses de estudio! Un excelente libro y una adición bienvenida a mi biblioteca Java ". -Jane Griscti, I / T asesor especialista
www.it-ebooks.info
Effective Java ™ Segunda edición
www.it-ebooks.info
El ™ Serie Java Ken Arnold, James Gosling, David Holmes El lenguaje de programación Java ™, Cuarta Edición
Eric Jendrock, Jennifer Bola El Java™EE 5 Tutorial, tercera edición
Joshua Bloch Effective Java Programming Language Guide ™
Jonni Kanerva El FAQ de Java ™
Joshua Bloch Effective Java ™, Segunda Edición
Jonathan Knudsen Kicking Butt con MIDP y MSA: Creando Gran Aplicaciones Móviles
Stephanie Bodoff, Dale Green, Kim Haase, Eric Jendrock El Tutorial J2EE ™, segunda edición María Campione, Kathy Walrath, Alison Huml El Tutorial de Java ™, tercera edición: Un Curso Corto en los conceptos básicos María Campione, Kathy Walrath, Alison Huml, La Equipo Tutorial El Tutorial de Java ™ Continúa: El Resto del JDK ™ Patrick Chan El Java ™ Desarrolladores Almanaque 1,4, Volumen 1 Patrick Chan El Java ™ Desarrolladores Almanaque 1,4, Volumen 2
David Lambert Venta inteligente: Estrategias de Venta Consultiva para satisfacer Necesidades del comprador Cada Hora Doug Lea Programación Concurrente en Java ™, segunda edición: Principios y patrones de diseño Rosanna Lee, Scott Seligman JNDI API Tutorial y Referencia: Edificio DirectorioAplicaciones Java ™ activado Sheng Liang La interfaz nativa de Java ™: Guía del programador y Especificación
Patrick Chan, Rosanna Lee Tim Lindholm, Frank Yellin Las bibliotecas de clases de Java ™, segunda edición, volumen El2: Java ™ Virtual Machine Especificación, segunda edición java.applet, java.awt, java.beans Roger Riggs, Antero Taivalsaari, Jim Van Peursem, Jyri Patrick Chan, Rosanna Lee, Doug Kramer Huopaniemi, Mark Patel, Aleksi Uotila Las bibliotecas de clases de Java, Second Edition, Volume 1: Programación de los dispositivos inalámbricos con la Java ™ 2 Suplemento para la Java ™ 2 Platform, Standard Edition, Platform, Micro Edition, Second Edition v1.2 ™
Kirk Chen, Li Gong Programación Abierta Servicio Gateways con Java ™ Embedded Server
Rahul Sharma, Beth Stearns Tony Ng J2EE Connector Architecture ™ y Empresa Integración de Aplicaciones
Inderjeet Singh, Beth Stearns, Mark Johnson, Enterprise Zhiqun Chen Equipo Tecnología Java Card ™ para tarjetas inteligentes: ArquitecturaEl diseño de aplicaciones empresariales con J2EE ™ y la Guía del Programador Plataforma, segunda edición Maydene Fisher, Jon Ellis, Jonathan Bruce JDBC ™ Tutorial API y Referencia, Tercera Edición Eric Freeman, Susanne Hupfer, Ken Arnold JavaSpaces Principios ™, Patterns, and Practice Li Gong, Gary Ellison, Mary DAGEFÖRDE Dentro de Java ™ 2 Platform Seguridad, segunda edición: Arquitectura, Diseño API e implementación James Gosling, Bill Joy, Guy Steele, Gilad Bracha El Java ™ Language Specification, Tercera edición Chet Haase, Romain individuo Clientes Filthy Rich: Desarrollo y animación gráfica Efectos para aplicaciones de escritorio Java ™ Marcos Hapner, Rich Burridge, Rahul Sharma, Joseph Fialli, Kim Haase Java ™ Message Service API Tutorial y Referencia: Mensajería para la plataforma J2EE ™
Inderjeet Singh, Sean Brydon, Greg Murray, Vijay Ramachandran, Thierry Violleau, Beth Stearns Diseño de Servicios Web con J2EE ™ 1.4 Plataforma: JAX-RPC, SOAP y XML Tecnologías Kathy Walrath, Mary Campione, Alison Huml, Sharon Zakhour El Tutorial JFC Swing, Segunda edición: Una guía para La construcción de interfaces gráficas de usuario Steve Wilson, Jeff Kesselman Plataforma Java ™ Rendimiento: Estrategias y Tácticas Sharon Zakhour, Scott Hommel, Jacob Royal, Isaac Rabinovitch, Tom Risser, Mark Hoeber El Java™Tutorial, cuarta edición: Un Curso Corto sobre los Fundamentos
www.it-ebooks.info
Effective Java ™ Segunda edición
Joshua Bloch
Upper Saddle River, Nueva Jersey • Boston • • Indianapolis San Francisco Nueva York • Toronto • Montreal Londres • Munich • París • Madrid Ciudad del Cabo • Sydney • Tokio • Singapur • Ciudad de México
www.it-ebooks.info
Muchas de las denominaciones utilizadas por los fabricantes y vendedores para distinguir sus productos se consideran marcas comerciales. Donde estas designaciones aparecen en este libro, y el editor fue consciente de una reclamación de la marca, las designaciones han sido impreso con letra inicial mayúscula o en todas las capitales. Sun Microsystems, Inc. tiene derechos de propiedad intelectual relacionados con las implementaciones de la tecnología que se describen en este pubcación. En concreto, y sin limitación alguna, estos derechos de propiedad intelectual pueden incluir una o más patentes de Estados Unidos, porEign patentes o aplicaciones pendientes. Sun, Sun Microsystems, el logotipo de Sun, J2ME, J2EE, Java Card, y todas las marcas comerciales y logotipos basados en Sun y Java son el comerciomarcas comerciales o marcas comerciales registradas de Sun Microsystems, Inc., en los Estados Unidos y otros países. UNIX es una marca registrada marca registrada en los Estados Unidos y otros países, bajo licencia exclusiva de X / Open Company, Ltd. esta publicación CIÓN SE PROPORCIONA "TAL CUAL" SIN GARANTÍA DE NINGÚN TIPO, YA SEA EXPRESA O IMPLÍCITA, INCLUYENDO ING, PERO NO LIMITADO A, LAS GARANTÍAS DE COMERCIALIZACIÓN, IDONEIDAD PARA UN PROPÓSITO PARTICULAR O NO INFRACCIÓN. ESTA PUBLICACIÓN CONTENGA TÉCNICA INEXACTITUDES O ERRORES TIPOGRÁFICOS. CAMBIOS PERIODICOS PARA LA INFORMACIÓN AQUÍ; Estos cambios se incorporarán en nuevas ediciones de la publicación. SOL MICROSYSTEMS, INC PUEDEN EFECTUAR MEJORAS Y / O CAMBIOS EN EL PRODUCTO (S) Y / O EL PROGRAMA (S) DESCRITO ESTA PUBLICACIÓN EN pero CUALQUIER MOMENTO. El autor y el editor han cuidadoEN en la preparación de este libro, hacer ninguna garantía expresa o implícita de ningún tipo y no asumimos ninguna responsabilidad por errores u omisiones. No se asume responsabilidad por daños incidentales o consecuentes en conexión con o que surjan de la utilización de la información o programas contenidos en el presente documento. El editor ofrece excelentes descuentos en este libro cuando se pide una cantidad para compras al por mayor o ventas especiales, que puede incluir las versiones electrónicas y / o cubiertas personalizadas y contenido concreto a su negocio, los objetivos de formación, comercialización enfocar, y los intereses de la marca. Para obtener más información, póngase en contacto con: EE.UU. corporativos y gubernamentales de ventas (800) 382-3419
[email protected] Para las ventas fuera de los Estados Unidos, por favor póngase en contacto con: Ventas Internacionales
[email protected]
Visítenos en la Web: informit.com / aw
Biblioteca del Congreso Número de control: 2008926278 Copyright © 2008 Sun Microsystems, Inc. 4150 Red Circle, Santa Clara, California 95054 U.S.A Todos los derechos reservados. Impreso en los Estados Unidos de América. Esta publicación está protegida por derechos de autor, y permissión se debe obtener de la editorial antes de cualquier reproducción prohibida, el almacenamiento en sistemas de recuperación o transmisión en cualquier forma o por cualquier medio, de fotocopia electrónico, mecánico, de grabación, o así mismo. Para información con respecto a los permisos, escriba a: Pearson Education, Inc. Derechos y Contratos 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 -13 ISBN: 978-0-321-35668-0 ISBN-10: los 0-321-35668-3 Texto impreso en los Estados Unidos en papel reciclado en Courier en Stoughton, Massachusetts. Primera edición, mayo de 2008
www.it-ebooks.info
A mi familia: Cindy, Tim, y Matt
www.it-ebooks.info
Esta página ha sido dejada en blanco intencionalmente
www.it-ebooks.info
Contenido
Prólogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Prefacio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Xv Agradecimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix 1 Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.1 2 Creación y destrucción de objetos. . . . . . . . . . . . . . . . . . 0.5 Tema 1: Considere métodos de generador estáticos en lugar de constructores. . . 5 Tema 2: Considere un constructor cuando se enfrentan a muchos constructor parámetros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Tema 3: Hacer cumplir la propiedad singleton con un privado constructor o un tipo de enumeración. . . . . . . . . . . . . . . . . . . . . . . 17 Tema 4: Hacer cumplir noninstantiability con un constructor privado. . . . 19 Tema 5: Evitar la creación de objetos innecesarios. . . . . . . . . . . . . . . . . 20 Tema 6: Eliminar las referencias a objetos en desuso. . . . . . . . . . . . . . . . . 24 Tema 7: Evite los finalizadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 métodos comunes a todos los objetos. . . . . . . . . . . . . . . . . 0.33 Tema 8: Respete el contrato general, cuando se reemplace es igual a . . . . . Tema 9: Siempre override hashCode cuando anular es igual a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artículo 10: Siempre override toString . . . . . . . . . . . . . . . . . . . . . . . . Tema 11: Anulación clon juiciosamente. . . . . . . . . . . . . . . . . . . . . . . . Tema 12: Considerar la implementación de Comparable . . . . . . . . . . . . . . . .
33 45 51 54 62
ix www.it-ebooks.info
x
CONTENIDOS
4 clases e interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Tema 13: Minimizar la accesibilidad de clases y miembros. . . . . . 67 Artículo 14: En las clases públicas, utilizar métodos de acceso, campos no públicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Tema 15: Minimizar mutabilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Artículo 16: Composición de la Merced sobre la herencia. . . . . . . . . . . . . . . . . . 81 Tema 17: Diseño y documentación de la herencia o de lo prohíban. . 87 Artículo 18: Prefiero interfaces para las clases abstractas. . . . . . . . . . . . . . . . . . 93 Tema 19: Use las interfaces sólo para definir tipos. . . . . . . . . . . . . . . . . . . 98 Artículo 20: Prefiero las jerarquías de clase para las clases marcadas. . . . . . . . . . . . . 100 Tema 21: Utilizar la función de objetos para representar las estrategias. . . . . . . . . . . 103 Artículo 22: Favorecer clases miembro estáticas sobre no estático. . . . . . . . . . . 106
5 Los genéricos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Artículo 23: No utilice tipos primas en el nuevo código. . . . . . . . . . . . . . . . . . . 109 Artículo 24: Eliminar las advertencias sin marcar. . . . . . . . . . . . . . . . . . . . . 116 Artículo 25: Prefiero listas de matrices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Artículo 26: Favorecer tipos genéricos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Artículo 27: Favorecer métodos genéricos. . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Artículo 28: Uso limitado comodines para aumentar la flexibilidad de la API. . . . . 134 Artículo 29: Considere typesafe contenedores heterogéneos. . . . . . . . . . 142
6 Las enumeraciones y anotaciones. . . . . . . . . . . . . . . . . . . . . . . . 147Artículo 30: Use las enumeraciones en lugar de int constantes. . . . . . . . . . . . . . . . . 147 Artículo 31: Utilice los campos de instancia en lugar de los ordinales. . . . . . . . . . . . . . . 158 Artículo 32: Uso EnumSet en lugar de campos de bits. . . . . . . . . . . . . . . . . . . 159 Artículo 33: Uso EnumMap en lugar de indexación ordinal. . . . . . . . . . . . . 161 Artículo 34: Emular enumeraciones extensibles con interfaces. . . . . . . . . . . . 165 Artículo 35: Prefiero anotaciones a modelos de nomenclatura. . . . . . . . . . . . . . . 169 Artículo 36: utilizar siempre el Anular anotación. . . . . . . . . . . . 176 Artículo 37: Utilice las interfaces de marcador para definir tipos. . . . . . . . . . . . . . . 179
7 Métodos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Artículo 38: Compruebe los parámetros de validez. . . . . . . . . . . . . . . . . . . . . 181 Artículo 39: Haga copias de defensa cuando sea necesario. . . . . . . . . . . . . . . . 184 Artículo 40: firmas de los métodos de diseño cuidado. . . . . . . . . . . . . . . . . 189 Artículo 41: Uso sobrecarga juiciosamente. . . . . . . . . . . . . . . . . . . . . . . 191
www.it-ebooks.info
CONTENIDOS
xi
Artículo 42: Uso varargs juiciosamente. . . . . . . . . . . . . . . . . . . . . . . . . . 197 Artículo 43: Regreso arrays vacíos o colecciones, no nulos. . . . . . . . . 201 Artículo 44: Escribir comentarios de documentación para todos los elementos de la API expuestas. . . . 203
8 Programación General. . . . . . . . . . . . . . . . . . . . . . . . 0.209 Artículo 45: Reducir al mínimo el alcance de las variables locales. . . . . . . . .209 ..... . 212 Artículo 46: Prefiero for-each bucles tradicionales para bucles. . . . . . . . . 215 Artículo 47: Conocer y utilizar las bibliotecas. . . . . . . . . . . . . . . . . . . . . . . Artículo 48: Evitar flotador y doble si las respuestas exactas 218 son obligatorios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artículo 49: Prefiero tipos primitivos a los primitivos en caja. . . . . . . . . . . 221 224 Artículo 50: Evite las cadenas donde otros tipos son más apropiadas. . Artículo 51: Cuidado con el rendimiento de la concatenación de cadenas. . . 227 ... 228 Artículo 52: Consulte objetos por sus interfaces. . . . . . . . . . . . . . . . . Artículo 53: Prefiero interfaces para la reflexión. . . . . . . . . . . . . . . . . . . . . 230 233 Artículo 54: Use métodos nativos con criterio. . . . . . . . . . . . . . . . . . . . 234 Artículo 55: Optimizar juiciosamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Artículo 56: Se adhieren a los convenios de denominación generalmente aceptada. ....
9 Excepciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.241 Artículo 57: Utilizar excepciones solo para condiciones excepcionales. . . . .241 .. Artículo 58: Uso comprueba excepciones para condiciones recuperables y las excepciones de tiempo de ejecución de errores de programación. 244 ...... Artículo 59: Evitar el uso innecesario de excepciones comprobadas. . . . . . . 246 . Artículo 60: Favorecer el uso de las excepciones estándar. . . . . . . . . . . . . . . 248 . Artículo 61: El tiro excepciones apropiadas a la abstracción. . . . . . . 250 Artículo 62: Documentar todas las excepciones producidas por cada método.252 ..... Artículo 63: Incluir la información sobre fallos de captura en mensajes de detalle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artículo 64: Luchar por la atomicidad fracaso. . . . . . . . . . . . . . . . . . . . . . . 254 Artículo 65: No ignore excepciones. . . . . . . . . . . . . . . . . . . . . . . . . 256 258
10 Concurrencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.259 Artículo 66: Sincronizar el acceso a los datos mutables compartidos. . . . . . .259 .... Artículo 67: Evitar la sincronización excesiva. . . . . . . . . . . . . . . . . . 265 Artículo 68: Prefiero ejecutores y tareas a las roscas. . . . . . . . . . . . . . . . 271 Artículo 69: Prefiero utilidades de concurrencia a esperar y notificar. . . . . . . 273
www.it-ebooks.info
xii
CONTENIDOS
Artículo 70: Documento de seguridad de los subprocesos. . . . . . . . . . . . . . . . . . . . . . . . . . 278 Artículo 71: Utilice la inicialización perezosa juiciosamente. . . . . . . . . . . . . . . . . . 282 Artículo 72: No depende del programador de subprocesos. . . . . . . . . . . . . . . 286 Artículo 73: Evite los grupos de threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
11 serialización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Artículo 74: Implementar Serializable juiciosamente. . . . . . . . . . . . . . . 289 Artículo 75: Considere el uso de un formulario serializado personalizado. . . . . . . . . . . . . 295 Artículo 76: Escribir readObject métodos defensiva. . . . . . . . . . . . . 302 Artículo 77: Para el control de ejemplo, prefieren tipos enum a readResolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Artículo 78: Considere proxies de serialización en lugar de en serie instancias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Apéndice: artículos correspondientes a la Primera Edición. . . . . . 317 Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
www.it-ebooks.info
Prefacio
YoF un colega fuera a decir a usted, "Esposa de mí esta noche, hoy fabrica la comida inusual en una casa. ? Usted se unirá a "tres cosas probablemente pasan por su mente: tercero, que había sido invitado a la cena; segundo, que el Inglés no era su colala lengua materna de la liga; y en primer lugar, una buena dosis de perplejidad. Si usted ha estudiado alguna vez una segunda lengua a ti mismo y luego trató de usarlo fuera del aula, ya sabes que hay tres cosas que usted debe dominar: cómo el lenguaje se estructura (gramática), cómo nombrar las cosas que quieres hablar (Vocabulario), y las formas habituales y eficaces de decir las cosas de todos los días (Uso). Con demasiada frecuencia, sólo las dos primeras están cubiertas en el aula, y te encuentras hablantes nativos constantemente suprimir su risa a medida que tratan de hacer usted mismo entendido. Es lo mismo con un lenguaje de programación. Es necesario comprender la núcleo del lenguaje: ¿es algorítmica, funcional, orientado a objetos? Usted necesita saber el Vocabulario: ¿qué estructuras de datos, operaciones y servicios son proporcionados por la bibliotecas estándar? Y tiene que estar familiarizado con el habitual y efectiva maneras de estructurar su código. Libros sobre los lenguajes de programación a menudo cubren sólo los dos primeros, o discutir el uso de sólo esporádicamente. Tal vez es porque la primera dos son de alguna manera más fácil de escribir. Gramática y vocabulario son propiaslazos de la lengua solo, pero el uso es característico de una comunidad que la utiliza. El lenguaje de programación Java, por ejemplo, es orientado a objetos con un solo herencia y apoya una (declaración orientada) estilo de programación imperativa dentro cada método. Las bibliotecas de abordar el apoyo gráfico de visualización, creación de redes, districomputing buido, y la seguridad. Pero, ¿cómo es el lenguaje mejor puesto en uso en la práctica? Hay otro punto. Programas, a diferencia de frases habladas ya diferencia de la mayoría libros y revistas, son susceptibles de ser cambiado con el tiempo. Por lo general no es suficiente para producir código que funcione de manera eficaz y sean fácilmente comprensibles por otra perhijos; también hay que organizar el código para que sea fácil de modificar. Puede haber diez maneras de escribir código para una tarea T. De esos diez maneras, siete será torpe, ineficiente o desconcertante. De los otros tres, lo que es más probable que sea similar a la código necesario para la tarea T ' en la versión de software del año que viene?
xiii www.it-ebooks.info
xiv
PRÓLOGO
Existen numerosos libros de los cuales se puede aprender la gramática de la Java Lenguaje de programación, incluyendo El lenguaje de programación Java ™ por Arnold, Gosling, y Holmes [Arnold05] o La especificación del lenguaje Java ™ por Gosling, Alegría, su servidor, y Bracha [JLS]. Del mismo modo, hay docenas de libros sobre las bibliotecas y las API asociadas con el lenguaje de programación Java. Este libro aborda su tercera necesidad: el uso consuetudinario y eficaz. Joshua Bloch ha pasado años que se extiende, la implementación y el uso de la programación Java lenguaje de Sun Microsystems; él también ha leído un montón de código de otras personas, incluyendo la mía. Aquí se ofrece un buen consejo, organizada sistemáticamente, sobre la forma de estructurar su código para que funcione bien, para que otras personas puedan entenderlo, por lo que las modificaciones y mejoras en el futuro son menos propensos a causar dolores de cabezatal vez, incluso, para que sus programas serán agradables, elegante y graciosa.
De Guy L. Steele Jr. Burlington, Massachusetts 04 2001
www.it-ebooks.info
Prefacio
Prefacio a la Segunda Edición
LaMuchas cosas han pasado a la plataforma Java desde que escribí la primera edición de este libro en 2001, y ya es hora para una segunda edición. El conjunto más significativo de los cambios fue la incorporación de los genéricos, tipos de enumeración, anotaciones, autoboxing, y la for-each bucle en Java 5. Un primer segundo fue la adición de la nueva biblioteca de concurrencia, java.util.concurrent, También lanzado en Java 5. Con Gilad Bracha, tuve la buena fortuna de dirigir a los equipos que diseñaron las nuevas características del lenguaje. También tuve la buena fortuna de formar parte del equipo que diseñó y desarrolló la concurrencia biblioteca, que fue dirigido por Doug Lea. El otro gran cambio en la plataforma es la adopción generalizada de la moderna Entornos de desarrollo integrado (IDE), como Eclipse, IntelliJ IDEA, y NetBeans, y de herramientas de análisis estático, como FindBugs. Aunque no he sido involucrado en estos esfuerzos, me he beneficiado de ellos inmensamente y aprendí que afectan a la experiencia de desarrollo de Java. En 2004, me mudé de Sun a Google, pero he seguido mi participación en el desarrollo de la plataforma Java en los últimos cuatro años, contribuyendo a la APIs de concurrencia y colecciones a través de los buenos oficios de Google y Java Proceso de Comunidad. También he tenido el placer de utilizar la plataforma Java para desarrollar bibliotecas para su uso dentro de Google. Ahora sé lo que se siente al ser un usuario. Como fue el caso en 2001 cuando escribí la primera edición, mi objetivo principal es compartir mi experiencia con ustedes para que pueda imitar mis éxitos y evitar mis fracasos. El nuevo material sigue haciendo un uso liberal de real examenpios de las bibliotecas de la plataforma Java. La primera edición tuvo éxito más allá de mis expectativas más optimistas, y yo he hecho mi la mejor manera de permanecer fiel a su espíritu, mientras cubría todo el nuevo material que fue solicitársele que lleve el libro hasta la fecha. Era inevitable que el libro iba a crecer, y crecer lo hizo, cincuenta hasta siete elementos a setenta y ocho. No sólo tenía que añadir veintitrés artículos, pero revisé a fondo todo el material original y me retiré un
xv www.it-ebooks.info
xvi
PRÓLOGO
algunos artículos cuyos mejores días habían pasado. En el apéndice, se puede ver cómo el En este libro se refiere al material en la primera edición. En el prefacio a la primera edición, escribí que el lenguaje de programación Java y sus bibliotecas eran inmensamente favorable a la calidad y la productividad, y una alegría para trabajar con. Los cambios en las emisiones 5 y 6 han tomado una buena cosa y lo hizo mejor. La plataforma es mucho más grande de lo que era en 2001 y más complejo, pero una vez que aprenda los patrones y frases hechas para el uso de las nuevas características, que hacen sus programas mejor y su vida más fácil. Espero que esta edición capta mi contiUED entusiasmo por la plataforma y ayuda a que su uso de la plataforma y su nuevas características más eficaz y agradable.
San Jose, California 04 2008
Prefacio a la primera edición En 1996 me detuve en juego y se dirigió al oeste para trabajar para JavaSoft, como lo era entonces conocido, porque estaba claro que allí era donde estaba la acción. En el intervalo de cinco años que he servido como bibliotecas de la plataforma Java arquitecto. He diseñado, implementado, y mantiene muchas de las bibliotecas y se desempeñó como consultor para muchos otros. Presidiendo estas bibliotecas como la plataforma Java madurado era una vez que-en unoportunidad de su vida. No es ninguna exageración decir que tuve el privilegio de trabajar con algunos de los grandes ingenieros de software de nuestra generación. En el proceso, he aprendido mucho sobre el lenguaje de programación Java, lo que funciona, lo que no, y cómo usarlo el lenguaje y sus bibliotecas de la mejor manera. Este libro es mi intento de compartir mi experiencia con ustedes para que pueda mimetizar litar mis éxitos, evitando mis fracasos. Tomé prestado el formato de Scott De Meyers A partir del C + + [Meyers98], que consta de cincuenta artículos, cada transmitiring una regla específica para mejorar sus programas y diseños. Encontré el formato ser singularmente eficaz, y espero que tú también. En muchos casos, me tomé la libertad de ilustrar los artículos con el mundo real ejemplos de las bibliotecas de la plataforma Java. Cuando se describe algo que podría haber hecho mejor, traté de recoger el código que escribí yo mismo, pero de vez en cuando Recojo en algo escrito por un colega. Me disculpo sinceramente si, a pesar de mi mejores esfuerzos, he ofendido a nadie. Ejemplos negativos se citan para no echar la culpa
www.it-ebooks.info
PRÓLOGO
xvii
pero en el espíritu de cooperación, a fin de que todos podamos aprovechar la experiencia de aquellos que han ido antes. Aunque este libro no está dirigido únicamente a los desarrolladores de componentes reutilizables, que se colorea inevitablemente por mi experiencia escribiendo tales componentes en los últimos dos décadas. Creo que de forma natural en términos de las API exportadas (Application Programming Interfaces), y os animo a hacer lo mismo. Incluso si usted no está desarrollando componentes reutilizables, pensando en estos términos tiende a mejorar la calidad de la software que escriba. Además, no es raro escribir una reutilizable componente sin saberlo: Escribes algo útil, compartirlo con su amigo otro lado del pasillo, y en poco tiempo usted tiene media docena de usuarios. En este punto, usted no ya tener la flexibilidad de cambiar el API en la voluntad y son agradecidos por todo el esfuerzo que usted pone en el diseño de la API de la primera vez que escribió el software. Mi enfoque en el diseño de la API puede parecer un poco antinatural para los devotos de la nueva metodologías de desarrollo de software ligero, como Extreme Programming [Beck99]. Estas metodologías enfatizan escribir el programa más simple que posiblemente podría trabajar. Si está utilizando uno de estos métodos, usted encontrará que un enfoque en el diseño de la API que sirve bien en la refactorización proceso. La fundamental objetivos de refactorización son la mejora de la estructura del sistema y la evitación de la duplicación de código. Estas metas son imposibles de alcanzar en ausencia de bienAPIs diseñadas para los componentes del sistema. Ninguna lengua es perfecto, pero algunos son excelentes. He encontrado el Java lenguaje de programación y sus bibliotecas a ser inmensamente favorable a la calidad y productividad, y un placer trabajar con ella. Espero que este libro capta mi entusiasmo y ayuda a que su uso del lenguaje más eficaz y agradable.
Cupertino, California 04 2001
www.it-ebooks.info
Esta página ha sido dejada en blanco intencionalmente
www.it-ebooks.info
Agradecimientos
Agradecimientos para la Segunda Edición
Yoagradecer a los lectores de la primera edición de este libro para darle tal naturaleza y entusiasta recepción, para la toma de sus ideas para el corazón, y por dejarme saber lo que es un influencia positiva que tuvo en ellos y su trabajo. Doy las gracias a los muchos profesores que utilizado el libro en sus cursos, y los muchos equipos de ingenieros que lo adoptaron. Doy las gracias a todo el equipo de Addison-Wesley para su amabilidad, profesiónlismo, la paciencia, y la gracia bajo presión. A pesar de todo, mi editor Greg Doench permanecido imperturbable: una multa editor y un perfecto caballero. Mi producción de manager, Julie Nahil, era todo lo que un gerente de producción debe ser: diligente, rápida, organizada y amigable. Mi editor, Barbara Wood, era meticuloso y de buen gusto. He estado una vez más bendecido con el mejor equipo de revisores imaginables, y le doy mi más sincero agradecimiento a cada uno de ellos. El equipo central, que revisó cada capítulo, consistió en Lexi Baugher, Cindy Bloch, Beth Bottos, Joe Bowbeer, Brian Goetz, Tim Halloran, Brian Kernighan, Rob Konigsberg, Tim Peierls, Bill Pugh, Yoshiki Shibata, Peter Stout, Peter Weinberger, y Frank Yellin. Otro revisores incluyeron Pablo Bellver, Dan Bloch, Dan Bornstein, Kevin Bourrillion, Martin Buchholz, Joe Darcy, Neal Gafter, Laurence Gonsalves, Aaron Greencasa, Barry Hayes, Peter Jones, Angelika Langer, Doug Lea, Bob Lee, Jeremy Manson, Tom May, Mike McCloskey, Andriy Tereshchenko, y Paul Tyma. Una vez más, estos revisores hicieron numerosas sugerencias que dieron lugar a una gran mejora mentos en este libro y me salvó de muchas situaciones embarazosas. Y de nuevo, cualquier restantes vergüenzas son mi responsabilidad. Doy gracias especiales a Doug Lea y Tim Peierls, quien se desempeñó como sonando tablas para muchas de las ideas de este libro. Doug y Tim era infaliblemente geunidades organizativas con su tiempo y conocimientos. Doy gracias a mi gerente de Google, Prabha Krishna, por su continuo apoyo y estímulo.
xix www.it-ebooks.info
xx
AGRADECIMIENTOS
Finalmente, agradezco a mi esposa, Cindy Bloch, por animarme a escribir, para leerción cada elemento en forma cruda, por ayudarme con Framemaker, para escribir el índice, y por aguantarme a mí mientras escribía.
Agradecimientos por la Primera Edición Doy las gracias a Patrick Chan por sugerir que escribo este libro y por lanzar la idea de Lisa es amable, el jefe de redacción series; Tim Lindholm, el editor técnico series; y Mike Hendrickson, editor ejecutivo de Addison-Wesley. Doy las gracias a Lisa, Tim, y Mike por animarme a continuar con el proyecto y por su paciencia sobrehumana y la fe inquebrantable que algún día escribir este libro. Doy las gracias a James Gosling y su equipo original para darme algo grande Escribo sobre, y agradezco a los muchos ingenieros de la plataforma Java que siguieron Los pasos de James. En particular, agradezco a mis colegas de Sun Java Platform Herramientas y Bibliotecas Grupo por sus ideas, su aliento y su apoyopuerto. El equipo está formado por Andrew Bennett, Joe Darcy, Neal Gafter, Iris García, Konstantin Kladko, Ian Little, Mike McCloskey, y Mark Reinhold. Ex miembros incluyen Zhenghua Li, Bill Maddox, y Naveen Sanjeeva. Doy gracias a mi manager, Andrew Bennett, y mi director, Larry Abrahams, para prestar su apoyo pleno y entusiasta a este proyecto. Doy las gracias a Rich Green, el VP de Ingeniería de software de Java, para proporcionar un entorno en el ingeros son libres de pensar de forma creativa y para publicar su trabajo. He sido bendecido con el mejor equipo de revisores imaginables, y doy mi más sincero agradecimiento a cada uno de ellos: Andrew Bennett, Cindy Bloch, Dan Bloch, Beth Bottos, Joe Bowbeer, Gilad Bracha, Mary Campione, Joe Darcy, David Eckhardt, Joe Fialli, Lisa friendly, James Gosling, Peter Haggar, David Holmes, Brian Kernighan, Konstantin Kladko, Doug Lea, Zhenghua Li, Tim Lindholm, Mike McCloskey, Tim Peierls, Mark Reinhold, Ken Russell, Bill Shannon, Peter Stout, Phil Wadler, y dos revisores anónimos. Ellos hicieron numerosas sugerencias que dio lugar a grandes mejoras en este libro y me salvó de muchos vergüenzas. Cualquier vergüenzas restantes son mi responsabilidad. Numerosos colegas, dentro y fuera de Sun, participaron en técnica discusiones que mejoraron la calidad de este libro. Entre otros, Ben Gomes, Steffen Grarup, Peter Kessler, Richard Roda, John Rose, y David Stoutamire
www.it-ebooks.info
AGRADECIMIENTOS
xxi
contribuido ideas útiles. Un agradecimiento especial se debe Doug Lea, quien se desempeñó como caja de resonancia de muchas de las ideas de este libro. Doug ha sido indefectiblemente generoso con su tiempo y sus conocimientos. Doy las gracias a Julie Dinicola, Jacqui Doucette, Mike Hendrickson, Heather Olszyk, Tracy Russ, y todo el equipo de Addison-Wesley por su apoyo y profelismo. Incluso bajo un calendario increíblemente apretado, siempre fueron muy amables y servicial. Doy las gracias de Guy Steele para escribir el prólogo. Me siento honrado de que él eligió participar en este proyecto. Finalmente, agradezco a mi esposa, Cindy Bloch, para fomentar y ocasionalmente amenazándome a escribir este libro, para la lectura de cada elemento en su forma cruda, en busca de ayudame ing con Framemaker, para escribir el índice, y por aguantarme a mí mientras yo escribió.
www.it-ebooks.info
Esta página ha sido dejada en blanco intencionalmente
www.it-ebooks.info
CAPÍTUL
1
Introducción TSu libro está diseñado para ayudarle a hacer el uso más eficaz de la Java
™
lenguaje de programación y sus bibliotecas fundamentales, java.lang,java.util, y, en menor medida, java.util.concurrent y java.io. El libro discute otras bibliotecas de vez en cuando, pero no cubre la interfaz gráfica de usuario programación, APIs empresariales, o los dispositivos móviles. Este libro consta de setenta y ocho artículos, cada uno de los cuales transmite una regla. Las prácticas de las normas de captura generalmente celebradas a ser beneficioso por la mejor y más programadores experimentados. Los elementos se agrupan libremente en diez capítulos, cada uno relativa a un aspecto amplio de diseño de software. El libro no se pretende que sea leer de principio a fin: cada elemento se sostiene por sí, más o menos. Los artículos son fuertemente con referencias cruzadas para que pueda trazar fácilmente su propio curso a través del libro. Muchas nuevas características se han añadido a la plataforma en Java 5 (versión 1.5). La mayor parte de los elementos de este manual utilizan estas características de alguna manera. La siguiente tabla muestra a dónde ir para la cobertura primaria de estas características: Característica
Capítulo o artículo
Genéricos
Capítulo 5
Las enumeraciones Anotaciones
Artículos 30 a 34
Con fines de cada bucle
Artículo 46
Autoboxing
Los artículos 40, 49
Varargs
Artículo 42
Importación estática
Artículo 19
java.util.concurrent
Los artículos 68, 69
Artículos 35 a 37
1 www.it-ebooks.info
2
CAPÍTULO 1
INTRODUCCIÓN
La mayoría de los artículos se ilustran con ejemplos de programas. Una característica clave de este libro es que contiene ejemplos de código que ilustran muchos patrones de diseño y modismos. En su caso, se les referencias cruzadas a la obra de referencia en este ámbito [Gamma95]. Muchos artículos contienen uno o más ejemplos de programas que ilustran un poco de práctica que debe evitarse. Tales ejemplos, a veces conocido como antipatrones, son claramente marcado con un comentario como "/ / Nunca hagas esto!"En cada caso, el elemento explica por qué el ejemplo es malo, y sugiere un enfoque alternativo. Este libro no es para principiantes: se supone que ya se siente cómodo con el lenguaje de programación Java. Si no es así, considere uno de los muchos bien textos introductorios [Arnold05, Sestoft05]. Mientras que el libro está diseñado para ser accesible a cualquier persona con un conocimiento práctico de la lengua, se debe proporcionar alimentos para el pensamiento, incluso para programadores avanzados. La mayor parte de las reglas de este libro se derivan de una serie de principios fundamentales. Clardad y la sencillez son de suma importancia. El usuario de un módulo debe nunca ser sorprendido por su comportamiento. Los módulos deben ser lo más pequeño posible, pero no más pequeño. (Tal como se utiliza en este libro, el término módulo se refiere a cualquier software reutilizable componente, a partir de un método individual a un sistema complejo que consta de múltiples los paquetes.) Código debería ser reutiliza en lugar de copiar. Las dependencias entre módulos deben mantenerse al mínimo. Los errores deben ser detectados tan pronto como sea posible después de que se hacen, a ser posible en tiempo de compilación. Si bien las reglas de este libro no se aplican al 100 por ciento de las veces, lo hacen caracterizar las mejores prácticas de programación en la gran mayoría de los casos. Usted no debe seguir ciegamente estas reglas, pero violarlos sólo ocasionalmente y con buena razón. Aprender el arte de la programación, como la mayoría de otras disciplinas, consiste primero aprender las reglas y luego aprender cuando romperlas. En su mayor parte, este libro no es sobre el rendimiento. Se acerca escribiendo programos que son clara, correcta, útil, robusta, flexible y fácil de mantener. Si puede hacer eso, por lo general es una cuestión relativamente sencilla para obtener el rendimiento que necesita (Artículo 55). Algunos elementos hacen discutir los problemas de rendimiento, y algunos de estos artículos proporcionar los números de rendimiento. Estos números, que se introducen con la frase "En mi máquina," debe considerarse como aproximadas en el mejor. Por si sirve de algo, mi máquina es una construcción casera de envejecimiento 2,2 GHz dual-core AMD Opteron ™ 170 con 2 gigabytes de RAM, corriendo de Sun 1.6_05 liberación de el Java SE Development Kit (JDK) encima de Microsoft Windows ® XP Professional SP2. Este JDK tiene dos máquinas virtuales, el cliente de Java HotSpot ™ y el servidor VMs. Las cifras de rendimiento se midieron en la VM Server.
www.it-ebooks.info
CAPÍTULO 1
INTRODUCCIÓN
3
Cuando se habla de las características del lenguaje de programación Java y sus bibliotecas, a veces es necesario hacer referencia a versiones específicas. Por razones de brevedad, este libro utiliza "los números de versión de ingeniería" en preferencia a los nombres de lanzamiento oficial. Esta tabla muestra la asignación entre los nombres de la versión y los números de versión de la ingeniería. Oficial Nombre de la liberación
Ingeniería Número de versión
JDK 1.1.x / JRE 1.1.x
1.1
Java 2 Platform, Standard Edition, v 1.2
1.2
Java 2 Platform, Standard Edition, v 1.3
1.3
Java 2 Platform, Standard Edition, v 1.4
1.4
Java 2 Platform, Standard Edition, v 5.0
1.5
Java Platform, Standard Edition 6
1.6
Los ejemplos están razonablemente completa, pero desean que se convoque la legibilidad sobre comcompletitud. Ellos utilizan libremente las clases de los paquetes java.util y java.io. En Para compilar los ejemplos, es posible que tenga que añadir una o más de estas importaciones declaraciones: java.util import *.; java.util.concurrent import *.; import java.io. *;
Otros repetitivo se omite de manera similar. El sitio web del libro, http:// java.sun.com / docs / books / efectiva, Contiene una versión ampliada de cada ejemplo, que se puede compilar y ejecutar. En su mayor parte, este libro utiliza términos técnicos tal como se definen en La Java Language Specification, Tercera edición [JLS]. Unos términos merecen especial mencionar. El lenguaje soporta cuatro tipos de tipos: interfaces de (Incluyendo annotaciones), clases de (Incluyendo enumeraciones), arrays, y primitivas. Los tres primeros son conocidos como los tipos de referencia. Instancias de clase y las matrices son objetos; valores primitivos no lo son. De una clase miembros consistir en su campos, métodos, clases de miembros, y miembro interfaces. De un método firma consiste en su nombre y el tipo de sus obligaciones formales parámetros; la firma hace no incluir el tipo de devolución del método. Este libro utiliza algunos términos de manera diferente de la El lenguaje Java Specification ción. Desemejante La especificación del lenguaje Java, Este libro utiliza herencia como synonym para subclases. En lugar de utilizar el término herencia para las interfaces, este
www.it-ebooks.info
4
CAPÍTULO 1
INTRODUCCIÓN
libro se limita a establecer que una clase implementos una interfaz o que una interfaz se extiende otra. Describir el nivel de acceso que se aplica cuando no se especifica ninguno, Este libro utiliza el término descriptivo paquete-privada en lugar de la técnica corplazo rect acceso predeterminado [JLS, 6.6.1]. Este libro utiliza algunos términos técnicos que no están definidos en El Java Languaje Specification. El término API exportada, o simplemente API, se refiere a las clases, interfaces, constructores, miembros y formularios serializados por el cual un programador accede a una clase, interfaz o paquete. (El término API, que es la abreviatura de aplicación interfaz de programación ción, se utiliza con preferencia al término de otra manera preferible interfaz para evitar la confusión con la construcción del lenguaje de ese nombre.) Un proGrammer que escribe un programa que utiliza una API se refiere como un usuario de la API. Una clase cuya aplicación utiliza una API es un cliente de la API. Las clases, interfaces, constructores, miembros y formularios serializados son colecmente conocido como Elementos de la API. Una API exportada se compone de los elementos de la API que son accesibles exterior del paquete que define la API. Estos son los ele-API mentos que cualquier cliente puede utilizar y el autor de la API se compromete a apoyar. No coincidentemente, también son los elementos para los que la utilidad Javadoc genera documentación en su modo de funcionamiento por defecto. Libremente hablando, el exportado API de un paquete se compone de los miembros públicos y protegidos y constructores de cada clase o interfaz pública en el paquete.
www.it-ebooks.info
CAPÍTUL
2
Creación y destrucción de objetos TSu capítulo preocupaciones Creación y destrucción de objetos: cuándo y cómo crear ellos, cuándo y cómo evitar la creación de ellos, la forma de garantizar que sean destruidos en un tiempo y forma, y la forma de gestionar las acciones de limpieza que deben preceder su destrucción.
Tema 1: Considere métodos de generador estáticos en lugar de constructores La forma normal de una clase para permitir a un cliente para obtener una instancia de sí mismo es procionar un constructor público. Existe otra técnica que debe ser una parte de todos los kit de herramientas del programador. Una clase puede ofrecer a un público método de fábrica estática, que es simplemente un método estático que devuelve una instancia de la clase. Aquí está un examen simple plo de Boolean (La clase primitiva caja para el tipo primitivo boolean). Este método traduce un boolean valor simple en un Boolean referencia de objeto: static Boolean valueOf (boolean b) { volver b? Boolean.TRUE: Boolean.FALSE; }
Tenga en cuenta que un método de fábrica estática no es el mismo que el Factory Method patrón desde Patrones de Diseño [Gamma95, p. 107]. El método de fábrica estática se describe en Este artículo no tiene equivalente directo en Patrones de diseño. Una clase puede ofrecer a sus clientes los métodos estáticos de la fábrica en lugar de, o en Además, los constructores. Proporcionar un método de fábrica estática en lugar de un público constructor tiene tanto ventajas como desventajas. Una de las ventajas de los métodos de fábrica estáticos es que, a diferencia de los constructores, se tienen nombres. Si los parámetros de un constructor no lo hacen, en sí mismas, describir el objeto que se devuelve, una fábrica estática con un nombre bien elegido es fácilier de usar y el código de cliente que resulta más fácil de leer. Por ejemplo, el constructor
5 www.it-ebooks.info
6
CAPÍTULO 2
Crear y destruir objetos
BigInteger (int, int, Random) que ,
devuelve una BigInteger que es probablemente prime, se habría expresado mejor como un método de fábrica estático denominado Biginteger.probablePrime. (Este método fue finalmente añadió en el comunicado de 1.4.) Una clase sólo puede tener un único constructor con una firma determinada. Programadores se han sabido para evitar esta restricción, proporcionando dos constructores cuyo parámetro listas sólo difieren en el orden de sus tipos de parámetros. Este es un muy mala idea. El usuario de una API como nunca será capaz de recordar lo que constructor es cuál y acabará llamando a la persona equivocada por error. Personas lectura de códigos que utiliza estos constructores no sabrá lo que hace el código cona cabo en referencia a la documentación de la clase. Debido a que tienen nombres, métodos de generador estáticos no compartir la restricción discutido en el párrafo anterior. En los casos en que una clase parece requerir múltiples constructores ple con la misma firma, sustituyen a los constructores con estática facmétodos de historia y cuidadosamente elegidos nombres para resaltar sus diferencias. Una segunda ventaja de los métodos de fábrica estáticos es que, a diferencia de los constructores, no son necesarios para crear un nuevo objeto cada vez que están invocados. Este permite que las clases inmutables (artículo 15) para utilizar instancias preconstruidos, o caché casos a medida que se construyeron, y prescinden de ellos varias veces para evitar la creación de objetos duplicados innecesarios. La Boolean.valueOf (boolean) método ilustrados esta técnica: nunca crea un objeto. Esta técnica es similar a la Peso mosca patrón [Gamma95, p. 195]. Se puede mejorar el rendimiento si Se ruega a los objetos equivalentes a menudo, especialmente si son caros de crear. La capacidad de los métodos de fábrica estáticos para devolver el mismo objeto desde repetida invocaciones permite a clases para mantener un estricto control sobre lo que existen casos en cualquier momento. Las clases que hacen esto se dice que son instancia controlada. Hay varios razones para escribir clases de instancia controlada. Control Instancia permite a una clase garantiza que sea un producto único (artículo 3) o no instanciable (punto 4). Además, permite una clase inmutable (artículo 15) para que la garantía de que no hay dos casos iguales existir: a.equals (b) si y sólo si a == b. Si una clase tiene esta garantía, entonces su clilos padres pueden utilizar el == operador en lugar de la equals (Object) método, que puede como resultado un mejor rendimiento. Tipos Enum (artículo 30) ofrecen esta garantía. Una tercera ventaja de los métodos de fábrica estáticos es que, a diferencia de los constructores, pueden devolver un objeto de cualquier subtipo de su tipo de retorno. Esto le da una gran flexibilidad en la elección de la clase del objeto devuelto. Una aplicación de esta flexibilidad es que una API puede devolver objetos sin haciendo sus clases públicas. Ocultación de clases de implementación de esta manera conduce a una API muy compacto. Esta técnica se presta a marcos basadas en la interfaz (Artículo 18), donde las interfaces proporcionan tipos de retorno naturales de métodos de fábrica estáticas.
www.it-ebooks.info
TEMA 1: CONSIDERAR LA ESTÁTICA MÉTODOS DE FÁBRICA EN VEZ DE CONSTRUCTORES 7
Las interfaces no pueden tener métodos estáticos, por lo que, por convención, métodos de generador estáticos para una interfaz llamada Tipo se ponen en una clase no instanciable (punto 4) llamado Tipos. Por ejemplo, el marco de las colecciones de Java tiene treinta y dos de conveniencia implementaciones de las interfaces de colección, proporcionando colecciones inmodificables, colecciones sincronizado, y similares. Casi todas estas implementaciones son exportados a través de métodos de fábrica estáticos en una clase no instanciable (java.util.Colcolecciones). Las clases de los objetos devueltos son todos no pública. El API Collections Framework es mucho menor de lo que hubiera sido si exportó treinta y dos clases públicas separadas, una para cada uno de conveniencia implementación. No es sólo la mayor parte de la API que se reduce, pero el conceptual peso. El usuario sabe que el objeto devuelto tiene precisamente la API especificado por su interfaz, lo que no hay necesidad de leer documentación de la clase adicional para el clases de implementación. Además, utilizando un método de fábrica tales estática requiere el cliente para hacer referencia al objeto devuelto por su interfaz en lugar de su implementación ción de clase, que es generalmente una buena práctica (artículo 52). No sólo la clase de un objeto devuelto por un método de fábrica static sea pública, pero la clase puede variar de invocación a la invocación dependiendo los valores de los parámetros a la fábrica estática. Cualquier clase que es un subtipo de la tipo de retorno declarado es permisible. La clase del objeto devuelto también puede variar de versión a versión para una mayor facilidad de mantenimiento y rendimiento del software. La clase java.util.EnumSet (Artículo 32), introducido en la versión 1.5, no tiene constructores públicos, sólo las fábricas estáticas. Vuelven uno de dos implementaciones, dependiendo del tamaño del tipo de enumeración subyacente: si tiene sesenta y cuatro o menos elementos, como la mayoría de los tipos de enumeración hacen, las fábricas estáticas devuelven un RegularEnumSet
ejemplo, que está respaldado por un solo largo; si el tipo de enumeración tiene sesenta y cinco años o más elementos, las fábricas devuelven un JumboEnumSet ejemplo, respaldado por una largo array. La existencia de estas dos clases de implementación es invisible a los clientes. Si RegularEnumSet dejó de ofrecer ventajas de rendimiento para los pequeños tipos de enumeración, se podría ser eliminada de una versión futura sin efectos nocivos. Del mismo modo, un futuro liberación podría añadir una tercera o cuarta aplicación de la EnumSet si resultaba benefiCIAL para el rendimiento. Los clientes no saben ni les importa la clase del objeto que regresen de la fábrica; que les importa sólo que es un poco de la subclase de EnumSet. La clase de objeto devuelto por un método de fábrica estática ni siquiera tiene por qué existir en el momento de escribir la clase que contiene el método. Dicha fábrica estática flexibles métodos forman la base de marcos de proveedores de servicios, tales como la Base de Datos de Java API Connectivity (JDBC). Un marco de proveedor de servicio es un sistema en el cual múltiples proveedores de servicios implementar un servicio, y el sistema hace que la implementaciones a disposición de sus clientes, que evitan que aquéllas de las implementaciones.
www.it-ebooks.info
8
CAPÍTULO 2
Crear y destruir objetos
Hay tres componentes esenciales de un marco de servicios: una serinterfaz de vicio, que los proveedores implementen; un API de registro de proveedores, que el sistema utiliza para registrar las implementaciones, dando a los clientes acceso a las mismas; y un serAcceso vicio API, que los clientes utilizan para obtener una instancia del servicio. El servicio acceso a la API normalmente permite, pero no requiere que el cliente especifique algunos criterios para la elección de un proveedor. En la ausencia de tal especificación, la API devuelve un instancia de una implementación por defecto. La API de acceso al servicio es la "estática flexibles de fábrica "que forma la base del marco de proveedor de servicios. Un cuarto componente opcional de un marco de servicios es un servicio interfaz de proveedor, que los proveedores implementen para crear instancias de su servicio aplicación. En ausencia de un proveedor de servicios de interfaz, las implementaciones están registrados por nombre de clase y una instancia reflexiva (artículo 53). En el caso de los JDBC, Conexión juega la parte de la interfaz de servicio, DriverManager.registerDriver es la API de registro de proveedor, DriverManager.getConnection es la API de acceso a los servicios, y Conductor es la interfaz de proveedor de servicios. Existen numerosas variantes del patrón de marco proveedor de servicios. Para ejemplo, la API de acceso al servicio puede devolver una interfaz de servicio más rica que la requerida del proveedor, utilizando el patrón de adaptador [Gamma95, p. 139]. Aquí hay una aplicación sencilla con una interfaz de proveedor de servicios y un proveedor por defecto:
/ Servicio boceto / marco proveedor / / Interfaz de servicio Interfaz de servicio público { Métodos ... / / específica de servicio, entra aquí }
/ / Servicio de interfaz del proveedor Proveedor de interfaz pública { NewService Servicio (); }
/ / Clase no instanciable para el registro del servicio y el acceso Servicios public class { Servicios privados () {} / / Evita la creación de instancias (artículo 4) / / nombres de servicio con los servicios privados de los proveedores finales estáticos Mapa = nueva ConcurrentHashMap (); public static final String DEFAULT_PROVIDER_NAME = "";
www.it-ebooks.info
TEMA 1: CONSIDERAR LA ESTÁTICA MÉTODOS DE FÁBRICA EN VEZ DE CONSTRUCTORES 9
/ / Proveedor de API de registro public static void registerDefaultProvider (Proveedor p) { registerProvider (DEFAULT_PROVIDER_NAME, p); } public static void registerProvider (String nombre, Proveedor p) { providers.put (nombre, p); }
/ / Servicio de acceso a la API public static Servicio newInstance () { volver newInstance (DEFAULT_PROVIDER_NAME); } static Servicio newInstance (String nombre) { Proveedor p = providers.get (nombre); if (p == null) throw new IllegalArgumentException ( "Ningún proveedor registrado con el nombre:" + nombre); p.newService regresar (); }
}
Una cuarta ventaja de los métodos de fábrica estáticos es que reducen la VERbosity de crear instancias de tipo con parámetros. Por desgracia, debe especificar los parámetros de tipo al invocar el constructor de una clase parametrizada incluso si son evidentes por el contexto. Esto normalmente requiere que usted provea la parámetros de tipo dos veces en rápida sucesión:
Map m = new HashMap ();
Esta especificación redundante deja rápidamente doloroso como la longitud y la complejidad dad del incremento parámetros de tipo. Con fábricas estáticas, sin embargo, el compilador puede averiguar los parámetros de tipo para usted. Esto se conoce como la inferencia de tipos. Para ejemplo, suponer que HashMap siempre que esta fábrica estática: public static HashMap newInstance () { return new HashMap (); }
Posteriormente, se podría sustituir a la declaración prolijo arriba con esta alternativa sucinta: Map m = HashMap.newInstance ();
Algún día, el idioma puede realizar este tipo de inferencia de tipos de constructor invocaciones, así como las invocaciones de métodos, pero como de la liberación de 1,6, no lo hace.
www.it-ebooks.info
10
CAPÍTULO 2
Crear y destruir objetos
Desafortunadamente, las implementaciones de recogida estándar, tales como HashMap hacer no tienen métodos de fábrica como de la liberación de 1,6, pero se puede poner estos métodos en su propia clase de utilidad. Más importante aún, usted puede proporcionar este tipo de fábricas de electricidad estática en su clases con parámetros propios. La principal desventaja de proporcionar métodos de fábrica sólo estáticas es que clases sin constructores públicos o protegidos no pueden ser subclases. La mismo es cierto para las clases no públicas devueltos por las fábricas públicas estáticas. Por ejemplo, es imposible crear una subclase de cualquiera de las clases de implementación de conveniencia en el Marco de Colecciones. Podría decirse que esto puede ser una bendición disfrazada, ya que fomenta edades programadores utilizar la composición en vez de la herencia (artículo 16). Una segunda desventaja de los métodos de fábrica estáticas es que no son fácilmente distinguible de otros métodos estáticos. Ellos no se destacan en API documentación en la forma en que los constructores hacen, por lo que puede ser difícil de entender cómo crear una instancia de una clase que proporciona métodos de generador estáticos en lugar de constores. La herramienta Javadoc puede sacar algún día atención a los métodos estáticos de la fábrica. En Mientras tanto, usted puede reducir esta desventaja, llamando la atención a la electricidad estática factorios en clase o los comentarios de la interfaz, y mediante la adhesión a nombres común convenciones. Estos son algunos nombres comunes para los métodos estáticos de fábrica:
•valueOf-Devuelve una instancia que tiene, hablando en términos generales, el mismo valor que su parámetros. Tales fábricas estáticas son de tipo de conversión efectivamente métodos. •de-Una alternativa concisa para valueOf, Popularizado por EnumSet (Artículo 32). •getInstance-Devuelve una instancia que se describe por los parámetros, pero no se puede decir que tienen el mismo valor. En el caso de un singleton, getInstance no toma ningún parámetro y devuelve la única instancia. •newInstance-Al igual que getInstance, Excepto que newInstance garantiza que cada instancia devuelta es distinta de todas las demás. •conseguirTipo-Like getInstance, Sino que se utiliza cuando el método de fábrica se encuentra en una difeclase ent. Tipo indica el tipo de objeto devuelto por el método de fábrica. •nuevoTipo-Like newInstance, Sino que se utiliza cuando el método de fábrica se encuentra en una difeclase ent. Tipo indica el tipo de objeto devuelto por el método de fábrica. En resumen, los métodos de generador estáticos y constructores públicos ambos tienen su utiliza, y vale la pena entender sus méritos relativos. Fábricas menudo estáticos son preferable, por lo que evitar el reflejo de proporcionar constructores públicos sin antes considerar fábricas estáticas.
www.it-ebooks.info
Inciso 2: CONSIDERE UN CONSTRUCTOR cuando se enfrentan con los parámetros del constructor MUCHOS 11
Tema 2: Considere la posibilidad de un constructor cuando se enfrentan a muchos constructor parámetros Fábricas estáticos y constructores comparten una limitación: no escala bien a grande número de parámetros opcionales. Consideremos el caso de una clase que representa el Etiqueta de información nutricional que aparece en los alimentos envasados. Estas etiquetas tienen algunos campos obligatorios-tamaño de la porción, porciones por envase, y las calorías por porcióny más de veinte opcional grasa campos-totales, grasas saturadas, grasas trans, colesterol, de sodio, y así sucesivamente. La mayoría de los productos tienen valores distintos de cero por sólo unos pocos de estos campos opcionales. ¿Qué clase de constructores o fábricas estáticas debe escribir para una clase de este tipo? Tradicionalmente, los programadores han utilizado el constructor telescópico patrón, en que proporcione un constructor con sólo los parámetros, otra con un requeridas solo parámetro opcional, una tercera con dos parámetros opcionales, y así sucesivamente, culminación rios de un constructor con todos los parámetros opcionales. Así es como se ve en práctica. Para ser breves, sólo cuatro campos opcionales se indican:
Patrón constructor / / telescópico - no escala bien! NutritionFacts public class { int final privado servingSize ;/ / (ml) requiere raciones privadas finales int ;/ / (por contenedor) requirieron calorías int final privado ;/ / opcional final privado int grasa ;/ / (g) opcional private int final de sodio ;/ / (mg) opcional carbohidratos final int privado; / / (G) opcional
NutritionFacts públicas (int servingSize, int porciones) { esto (servingSize, porciones, 0); } NutritionFacts públicos (int servingSize, int porciones, int calorías) { esto (servingSize, porciones, calorías, 0); }
NutritionFacts públicos (int servingSize, int porciones, int calorías, grasa int) { esto (servingSize, porciones, calorías, grasa, 0); }
NutritionFacts públicos (int servingSize, int porciones, int calorías, grasa int, int sodio) { esto (servingSize, porciones, calorías, grasa, sodio, 0); }
www.it-ebooks.info
12
CAPÍTULO 2
Crear y destruir objetos
NutritionFacts públicos (int servingSize, int porciones, int, int calorías de grasa, sodio int, int carbohidratos) { this.servingSize = servingSize; this.servings = porciones; this.calories = calorías; this.fat = grasa; this.sodium = de sodio; this.carbohydrate = hidratos de carbono; } }
Cuando desea crear una instancia, se utiliza el constructor con el menor lista de parámetros que contiene todos los parámetros que desea configurar: NutritionFacts cocacola = nuevos NutritionFacts (240, 8, 100, 0, 35, 27);
Normalmente esta invocación constructor requerirá muchos parámetros que usted no lo hace desea ajustar, pero te ves obligado a pasar un valor para ellos de todos modos. En este caso, pasado un valor de 0para grasa. Con "sólo" seis parámetros Esto puede no parecer tan malo, pero pronto se le va de las manos como el número de parámetros aumenta. En resumen, el patrón constructor telescópica funciona, pero es difícil escribir código de cliente cuando hay muchos parámetros, y más difícil todavía lo lean. La lector se queda preguntándose qué significan todos esos valores, y debe contar con atención parámetros para averiguar. Secuencias largas de parámetros de forma idéntica con tipo pueden causar errores sutiles. Si el cliente invierte accidentalmente dos de tales parámetros, el compilador No se quejará, pero el programa se portan mal en tiempo de ejecución (artículo 40). Una segunda alternativa cuando se enfrentan con muchos parámetros de constructor es la JavaBeans patrón, en el que se llama a un constructor sin parámetros para crear el objeto y luego llamar a los métodos setter para configurar cada parámetro requerido y cada uno parámetro opcional de interés:
/ / JavaBeans Patrón - permite la inconsistencia, mandatos mutabilidad NutritionFacts public class { / / Parámetros inicializan a valores por defecto (si los hay) private int servingSize = -1; / / Necesario; ningún valor predeterminado porciones private int = -1; / / "" "" calorías private int = 0; int grasa privado = 0; int sodio privada = 0; int carbohidratos privado = 0;
NutritionFacts públicas () {}
www.it-ebooks.info
Inciso 2: CONSIDERE UN CONSTRUCTOR cuando se enfrentan con los parámetros del constructor MUCHOS 13
/ / Setters public void public void public void public void public void public void
setServingSize (int val) setServings (int val) setCalories (int val) setFat (int val) setSodium (int val) setCarbohydrate (int val)
{ { { { { {
servingSize = val; } porciones = val; } calorías = val; } grasa = val; } sodio = val; } hidratos de carbono = Val; }
}
Este patrón tiene ninguna de las desventajas del patrón constructor telescópico. Es fácil, aunque un poco prolijo, para crear instancias, y fácil de leer el código resultante: NutritionFacts cocacola = new NutritionFacts (); cocaCola.setServingSize (240); cocaCola.setServings (8); cocaCola.setCalories (100); cocaCola.setSodium (35); cocaCola.setCarbohydrate (27);
Desafortunadamente, el patrón de JavaBeans tiene graves desventajas de su propia. Debido a que la construcción se divide en varias llamadas, un JavaBean puede estar en una estado inconsistente hasta la mitad a través de su construcción. La clase no tiene la opción de hacer cumplir la consistencia simplemente comprobando la validez de la conparámetros Structor. Intentar utilizar un objeto cuando está en un estado incoherente puede causar fallas que están muy lejos de el código que contiene el error, por lo tanto, difícil de depurar. Una desventaja es que relacionados el patrón de JavaBeans precluye la posibilidad de hacer una clase inmutable (Artículo 15), y requiere añadido de esfuerzo por parte del programador para garantizar la seguridad para subprocesos. Es posible reducir estos inconvenientes manualmente "congelar" el objeto cuando su construcción esté completa y no lo que le permite ser utilizado hasta que se congele, pero esta variante es difícil de manejar y rara vez se utiliza en la práctica. Por otra parte, puede causar errores en tiempo de ejecución, ya que el compilador no puede garantizar que el programador llama a la congelación método en un objeto antes de usarlo. Afortunadamente, hay una tercera alternativa que combina la seguridad de la telescópica patrón constructor con la legibilidad del patrón de JavaBeans. Es una forma de la Constructor patrón [Gamma95, p. 97]. En lugar de hacer el objeto deseado directamente, el cliente llama a un constructor (o de fábrica estática) con todos los parámetros necesarios y consigue un objeto constructor. A continuación, el cliente llama a los métodos setter-como en el constructor oponerse a ajustar cada parámetro opcional de interés. Por último, el cliente llama a un parámetro terless construir método para generar el objeto, que es inmutable. El constructor es un clase miembro estático (artículo 22) de la clase que construye. Así es como se ve en la práctica:
www.it-ebooks.info
14
CAPÍTULO 2
Crear y destruir objetos
/ / Patrón Constructor NutritionFacts public class { servingSize final int privado; porciones int final privado; calorías int final privado; grasa final int privado; int final de sodio privado; carbohidratos final int privado;
public class constructor static { / / Parámetros requeridos servingSize final int privado; porciones int final privado;
/ / Opcional private int private int private int private int
parámetros - inicializado a los valores por defecto calorías = 0; grasas = 0; hidratos de carbono = 0; de sodio = 0;
Constructor público (int servingSize, int porciones) { this.servingSize = servingSize; this.servings = porciones; }
calorías Builder público (int val) {Calorías = val; devuelva este; grasa Constructor público (int val) {Grasa = val; devuelva este; Constructor público carbohidratos (int val) {Carbohidratos = Val; devuelva este; Constructor público de sodio (int val) {Sodio = val; devuelva este;
} } } }
NutritionFacts públicas construyen () { volver nuevos NutritionFacts (this); } } NutritionFacts privado (Constructor Constructor) { servingSize = builder.servingSize; porciones = builder.servings; calorías = builder.calories; grasa = builder.fat; sodio = builder.sodium; carbohidratos = builder.carbohydrate; } }
www.it-ebooks.info
Inciso 2: CONSIDERE UN CONSTRUCTOR cuando se enfrentan con los parámetros del constructor MUCHOS 15
Tenga en cuenta que NutritionFacts es inmutable, y que todos los valores por defecto de los parámetros se encuentran en un solo lugar. Métodos de establecimiento del constructor devuelven el propio generador para que las invocaciones se pueden encadenar. Así es como se ve el código de cliente: NutritionFacts cocacola = new NutritionFacts.Builder (240, 8). ... calorías (100) de sodio (35) de hidratos de carbono (27) construcción ();
Este código de cliente es fácil de escribir y, sobre todo, para leer. El Generador de patsimula tern llamados parámetros opcionales como se encuentra en Ada y Python. Al igual que un constructor, un constructor puede imponer invariantes en sus parámetros. La construir método puede comprobar estos invariantes. Es crítico que ser comprobados después de copia de los parámetros del constructor para el objeto, y que se pueden verificar en los campos del objeto en lugar de los campos de generador (Tema 39). Si alguno de los invariantes son vioLated, la construir método debe lanzar una IllegalStateException (Artículo 60). La método de detalle de excepción debe indicar qué invariante es violado (artículo 63). Otra forma de imponer invariantes que involucran a múltiples parámetros es tener métodos setter toman grupos enteros de parámetros en los que algunos deben invariante sostener. Si el invariante no se cumple, el método setter lanza una IllegalArgumentException. Esto tiene la ventaja de detectar el fallo invariante tan pronto como se pasan los parámetros no válidos, en lugar de esperar a que construir que se invoca. La menor ventaja de los constructores sobre los constructores es que los constructores pueden tener multiple VarArgs parámetros. Constructores, al igual que los métodos, sólo puede tener un varargs parámetro. Debido a que los constructores utilizan métodos distintos para configurar cada parámetro, que pueden tienen hasta VarArgs parámetros a su gusto, hasta uno por método setter. El patrón Builder es flexible. Un único constructor puede ser usado para construir múltiples objetos. Los parámetros del constructor pueden ser ajustados entre las creaciones de objetos a variar los objetos. El constructor puede rellenar algunos campos automáticamente, como una serie cifra que se incrementa de forma automática cada vez que se crea un objeto. Un constructor cuyos parámetros se han establecido hace una multa Abstract Factory [Gamma95, p. 87]. En otras palabras, un cliente puede pasar un constructor de este tipo a un método para habilitar el método para crear uno o más objetos para el cliente. Para habilitar esta uso, se necesita un tipo para representar el constructor. Si está utilizando versión 1.5 o una después suelte, un tipo genérico simple (artículo 26) es suficiente para todo constructores, no importa qué tipo de objeto que están construyendo:
/ / Un constructor de objetos de tipo T interfaz pública Constructor { T build pública (); }
www.it-ebooks.info
16
CAPÍTULO 2
Crear y destruir objetos
Tenga en cuenta que nuestra NutritionFacts.Builder clase podría ser declarada de implementar Constructor . Los métodos que toman una Constructor ejemplo sería restringen normalmente el constructor de tipo de parámetro usando un tipo comodín acotada (Artículo 28). Por ejemplo, aquí hay una método que genera un árbol utilizando un cliente proporcionado por Constructor instancia para construir cada nodo: Árbol buildTree (Generador de
