Tema 1: Considere mtodos de fbrica estticas en lugar de constructores

Proporcionar un mtodo de fbrica esttica en lugar de un constructor pblico tiene ventajas y

desventajas.
Una de las ventajas de los mtodos de fbrica estticas es que, a diferencia de los
constructores, tienen nombres. Si los parmetros a un constructor no lo hacen, por s mismas,
describe el objeto que se devuelve, una fbrica esttica con un nombre bien elegido es ms
fcil de usar y el cdigo de cliente que resulta ms fcil de leer.
Una clase slo puede tener un nico constructor con una firma determinada. Los
programadores han sabido moverse por esta restriccin, proporcionando dos constructores
cuyas listas de parmetros difieren slo en el orden de sus tipos de parmetros. Esta es una
muy mala idea. El usuario de una API nunca ser capaz de recordar que constructor es cul y
acabar llamando el equivocado por error. La gente que lee el cdigo que utiliza estos
constructores no va a saber lo que hace el cdigo sin hacer referencia a la documentacin de la
clase.
Una segunda ventaja de los mtodos de fbrica estticas es que, a diferencia de los
constructores, ellas no estn obligados a crear un nuevo objeto cada vez que estn invocadas.
Esto permite que las clases inmutables (artculo 15) para utilizar instancias preconstruidos, o
para almacenar en cach los casos a medida que se construyen, y prescindir de ellos varias
veces para evitar la creacin de objetos duplicados innecesarios. Se puede mejorar en gran
medida el rendimiento si se solicitan objetos equivalentes a menudo, especialmente si son
caros para crear.
La capacidad de los mtodos de fbrica estticos para devolver el mismo objeto desde
invocaciones repetidas permite que las clases para mantener un estricto control sobre lo que
existen casos en cualquier momento. Las clases que hacen esto se dice que son instancias
controladas.
Una tercera ventaja de los mtodos de fbrica estticas es que, a diferencia de los
constructores, pueden devolver un objeto de cualquier subtipo de su tipo de cambio. Esto le
da una gran flexibilidad en la eleccin de la clase del objeto devuelto.
Una aplicacin de esta flexibilidad es que una API puede devolver los objetos sin hacer sus
clases pblico. Ocultando clases de implementacin de esta manera conduce a una API muy
compacto. Las interfaces no pueden tener mtodos estticos, por lo que por convencin, los
mtodos de fbrica estticas para una interfaz llamada Tipo se ponen en una clase no
instanciable
Hay tres componentes esenciales de un framework de servicios: un servicio de interfaz, que los
proveedores implementen; un proveedor de API de registro, que el sistema utiliza para
registrar las implementaciones, dando a los clientes el acceso a ellos; y un servicio de API de
acceso, que los clientes utilizan para obtener una instancia del servicio. Un cuarto componente
opcional de un framework de proveedor de servicios es una interfaz de proveedor de servicios,
que los proveedores implementen para crear instancias de su aplicacin de servicio.
Una cuarta ventaja de los mtodos de fbrica estticas es que reducen el nivel de detalle de la
creacin de instancias de tipo con parmetros. Por desgracia, debe especificar los parmetros
de tipo cuando se invoca el constructor de una clase parametrizada incluso si son evidentes
por el contexto. Con fbricas estticas, sin embargo, el compilador puede averiguar los
parmetros de tipo para usted. Esto se conoce como la inferencia de tipos.
La principal desventaja de proporcionar slo los mtodos de fbrica estticas es que las clases
sin constructores pblicos o protegidos no pueden ser subclases. Podra decirse que esto
puede ser una bendicin disfrazada, ya que favorece programadores utilizar la composicin en
vez de la herencia.
Una segunda desventaja de los mtodos de fbrica estticas es que no son fcilmente
distinguibles de otros mtodos estticos.
valueOf-Devuelve una instancia que tiene, hablando vagamente, el mismo valor que sus
parmetros. Estas fbricas estn estticos tipo de conversin efectiva mtodos.
of-A alternativa concisa para valueOf, popularizado por EnumSet
- getInstance-Devuelve una instancia que se describe por los parmetros pero no se
puede decir que tienen el mismo valor. En el caso de un producto nico, getInstance
no toma parmetros y devuelve la nica instancia.
- newInstance-Como getInstance, salvo que newInstance garantiza que cada instancia
devuelve es distinto de todos los dems.
- getType-Como getInstance, pero se utiliza cuando el mtodo de fbrica se encuentra
en una diferente clase. Type indica el tipo de objeto devuelto por el mtodo de fbrica.
- newType-Como newInstance, pero se utiliza cuando el mtodo de fbrica se
encuentra en una diferente clase. Type indica el tipo de objeto devuelto por el mtodo
de fbrica.
Tema 2: Considere un constructor cuando se enfrentan con muchos parmetros del
constructor
Fbricas estticas y constructores comparten una limitacin: no escala bien a un gran nmero
de parmetros opcionales.
Una segunda alternativa cuando se enfrentan con muchos parmetros del constructor es el
patrn JavaBeans, en el que se llama a un constructor sin parmetros para crear el objeto y
luego llamar a los mtodos setter para ajustar cada parmetro requerido y cada parmetro
opcional de inters:
public class NutritionFacts {
// Parameters initialized to default values (if any)
private int servingSize = -1; // Required; no default value
private int servings = -1; // " " " "
private int calories = 0;
public NutritionFacts() { }
public void setServingSize(int val) { servingSize = val; }
public void setServings(int val) { servings = val; }
public void setCalories(int val) { calories = val; }
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
JavaBean puede estar en un estado inconsistente un punto intermedio su construccin. el
patrn de JavaBeans se opone a la posibilidad de hacer una clase inmutable

Afortunadamente, hay una tercera alternativa que combina la seguridad del patrn
constructor telescpico con la legibilidad del patrn de JavaBeans. Es una forma del patrn
Builder. En lugar de hacer el objeto que desea directamente, el cliente llama a un constructor
(o fbrica esttica) con todos los parmetros exigidos y obtiene un objeto constructor. A
continuacin, el cliente llama a los mtodos setter-como en el objeto constructor para ajustar
cada parmetro opcional de inters. Por ltimo, el cliente llama a un mtodo de aumento sin
parmetros para generar el objeto, que es inmutable.
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
public static class Builder {
// Required parameters
private final int servingSize;
private final int servings;
// Optional parameters - initialized to default values
private int calories = 0;
public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}
public Builder calories(int val)
{ calories = val; return this; }
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
private NutritionFacts(Builder builder) {
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
calories(100).sodium(35).carbohydrate(27).build();
Tema 3: Hacer cumplir la propiedad singleton con un constructor privado o un tipo de
enumeracin
Un singleton es simplemente una clase que se crea una instancia exactamente una vez.
Singletons representan tpicamente un componente del sistema que es intrnsecamente nico,
como el gestor de ventanas o sistema de archivos.
Nada de un cliente puede cambiar esto, con una salvedad: un cliente privilegiado puede
invocar el constructor privado reflexivamente con la ayuda del mtodo
AccessibleObject.setAccessible.
La principal ventaja del enfoque campo pblico es que las declaraciones dejan claro que la
clase es un singleton: el campo public static es final, por lo que siempre contendr la misma
referencia de objeto.
Una de las ventajas del enfoque de fbrica mtodo es que le da la flexibilidad para cambiar de
opinin acerca de si la clase debe ser un singleton sin cambiar su API. Para mantener la
garanta singleton, usted tiene que declarar todas las instancias de campos transitorios y
proporcionar un mtodo readResolve.
Si bien este enfoque an no se ha adoptado ampliamente, un tipo de enumeracin de un solo
elemento es la mejor manera de poner en prctica un singleton.
Item 4: Hacer cumplir no instanciabilidad con un constructor privado
Se pueden utilizar los mtodos relacionados con el grupo sobre los valores primitivos o
matrices, a la manera de java.lang.Math o java.util.Arrays. Ellos tambin se pueden utilizar
para agrupar mtodos estticos, incluyendo mtodos de fbrica, para los objetos que
implementan una interfaz en particular, a la manera de java.util.Collections. Por ltimo,
pueden ser usados para mtodos de grupo en una clase final, en lugar de extender la clase.
El intento de hacer cumplir noninstantiability haciendo una clase abstracta no funciona. La
clase puede tener subclases y la subclase instancia. Adems, se engaa al usuario hacindole
creer a la clase fue diseada para la herencia
Hay, sin embargo, un lenguaje sencillo para asegurar noninstantiability. Se genera un
constructor por defecto slo si una clase no contiene constructores explcitas, por lo que una
clase se puede hacer no instanciable al incluir un constructor privado
public class UtilityClass {
// Suppress default constructor for noninstantiability
private UtilityClass() {
throw new AssertionError();
}
No se invoca por ser privado en subclases y el assert por dentro. Como efecto
secundario, este idioma tambin evita la clase de ser subclase.
Item 5: Evitar la creacin de objetos innecesarios
A menudo es apropiado volver a utilizar un solo objeto en vez de crear un nuevo objeto
funcionalmente equivalente cada vez que sea necesario. La reutilizacin puede ser tanto ms
rpido y ms elegante. Un objeto siempre puede volver a utilizar si es inmutable. A menudo se
puede evitar la creacin de objetos innecesarios mediante el uso de mtodos de fbrica
estticos en preferencia a los constructores de las clases inmutables que proporcionan ambos.
Adems de la reutilizacin de objetos inmutables, tambin se puede reutilizar objetos
mutables si usted sabe que no se pueden modificar.
La versin mejorada de la clase Persona crea Calendario, zona horaria, y los casos la fecha slo
una vez, cuando se inicializa, en lugar de crear ellos cada vez isBabyBoomer se invoca. Esto da
lugar a significativas mejoras de rendimiento si el mtodo es invocado frecuentemente.
No slo es un rendimiento mejorado, pero tambin lo es la claridad. Cambiando boomStart y
boomEnd de variables locales a campos static final deja claro que estas fechas son tratadas
como constantes, por lo que el cdigo sea ms comprensible.
prefieren primitivas a primitivas en caja, y cuidado con los autoboxing no intencional. El no
poder hacer copias de defensa cuando sea necesario puede conducir a errores insidiosos y
agujeros de seguridad; la creacin de objetos innecesariamente solamente afecta estilo y
rendimiento.
Item 6: Evitar la creacin de objetos innecesarios
Entonces, dnde est la prdida de memoria? Si una pila crece y luego se encoge, los objetos
que se hicieron estallar de la pila no sern basura recogida, incluso si el programa que usa la
pila no tiene ms referencias a ellos. Esto es porque la pila mantiene referencias obsoletas a
estos objetos. Una referencia obsoleta es simplemente una referencia que nunca se eliminan
las referencias de nuevo. En este caso, todas las referencias fuera de la "parte activa" de la
matriz de elemento son obsoletos. La parte activa se compone de los elementos cuyo ndice es
menor que el tamao.
La solucin para este tipo de problema es simple: referencias nulas fuera una vez que se
vuelven obsoletos. En el caso de nuestra clase Pila, la referencia a un elemento se convierte
obsoleta tan pronto como se le hizo estallar de la pila.
Un beneficio adicional de anulando las referencias obsoletas es que, si son posteriormente
desreferenciados por error, el programa fallar inmediatamente con un NullPointerException,
en lugar de hacerlo en silencio las cosas mal. Siempre es beneficioso para detectar errores de
programacin tan pronto como sea posible. La mejor manera de eliminar una referencia
obsoleta es dejar que la variable que contiene la cada de referencia fuera de alcance. Esto
ocurre de forma natural si se define cada variable en la ms estrecha grado posible
Otra fuente comn de prdidas de memoria es cachs. Una vez que usted pone una referencia
de objeto en una cach, es fcil olvidar que est ah y dejarlo en la cach mucho despus de
que se vuelve irrelevante. Una tercera fuente comn de prdidas de memoria es oyentes y
otras devoluciones de llamada.
Si implementa una API donde el cliente se registren devoluciones de llamada, pero no darse de
baja de forma explcita, ellas se acumularn a menos que tome alguna accin. La mejor
manera de garantizar que las devoluciones de llamada son basura recogida rpidamente es
almacenar referencias dbiles solamente a ellos, por ejemplo, mediante el almacenamiento de
ellos slo como claves en un WeakHashMap.
Item 7: evite Finalizadores
Finalizadores son impredecibles, a menudo peligroso, y generalmente innecesario. Su uso
puede provocar un comportamiento errtico, bajo rendimiento y problemas de portabilidad.
nunca se debe hacer en tiempo crtico un finalizador. Simplemente proporcione un mtodo de
terminacin explcito, y requieren los clientes de la clase para invocar este mtodo en cada
instancia cuando ya no es necesaria. Mtodos de terminacin explcitos se utilizan
normalmente en combinacin con la terminacin try-finally construir para asegurar.
En resumen, no utilice finalizadores excepto como una red de seguridad o de suspender los
recursos nativos no crticos. En aquellos casos excepcionales en los que usted hace uso de un
finalizador, recuerde que debe invocar super.finalize. Si utiliza un finalizador como red de
seguridad, recuerde registrar el uso no vlido desde el finalizador. Por ltimo, si usted necesita
para asociar un finalizador con una clase pblica no final, considere el uso de un tutor
finalizador, por lo que la finalizacin puede tener lugar incluso si un finalizador subclase no
invocar super.finalize.
MTODOS COMUNES PARA TODOS LOS OBJETOS
Tema 8: Obedecer el contrato general, cuando se sobreescriben iguales
Cada instancia de la clase es de por s nico. Esto es cierto para las clases tales como hilo que
representan entidades activas en lugar de valores. La implementacin equals proporcionada
por objeto tiene exactamente el comportamiento adecuado para estas clases.
No importa si la clase proporciona una prueba de la "igualdad lgica". Por ejemplo,
java.util.Random podra haber sobreescrito equals para comprobar si dos instancias aleatorias
produciran la misma secuencia de nmeros aleatorios a futuro, pero los diseadores no crea
que los clientes podran necesitar o desear esta funcionalidad. Bajo estas circunstancias, la
aplicacin equals heredado de Object es adecuada.
La clase es privada o paquete - privado, y usted est seguro de que no se invocar su mtodo
equals. Podra decirse que el mtodo equals debe ser sobreescrito bajo estas circunstancias,
en caso de que se invoca por accidente:
Una clase de valor es simplemente una clase que representa un valor, como enteros o Fecha.
Un programador que compara las referencias a los objetos de valor que utilizan mtodo equals
espera saber si son lgicamente equivalentes, no si se refieren al mismo objeto. Cuando se
reemplaza el mtodo equals, debe cumplir con su contrato general.
El mtodo equals implementa una relacin de equivalencia. Es:
Reflexiva: Para cualquier valor de referencia no nulo x, x.equals (x) deben devolver true.
simtrica: Para cualquier valor de referencia no nulos x e y, x.equals (y) debe devolver
verdadero si y slo si y.equals (x) devuelve true.
Transitiva: Para cualquier no nulos valores de referencia x, y, z, si x.equals (y) devuelve true y
y.equals (z) devuelve true, entonces x.equals (z) deben devolver true.
Consistente: Para cualquier valor de referencia no nulos x e y, mltiples invocaciones de
x.equals (y) constantemente return true o consistentemente return false, no proporcion
informacin utilizada en comparaciones equals en los objetos se modifica.
Para cualquier valor de referencia no nulo x, x.equals (null) debe devolver false.
El principio de sustitucin Liskov dice que cualquier propiedad importante de un tipo tambin
debe mantenerlo en los subtipos, de modo que cualquier mtodo escrito para el tipo debera
funcionar igual de bien en sus subtipos
Para tener un mtodo equals de calidad
Utilice el operador == para comprobar si el argumento es una referencia a este objeto.
Utilice el operador instanceof para comprobar si el argumento tiene el tipo correcto.
Cast el argumento con el tipo correcto.
Para cada campo "significativo" en la clase, compruebe si ese campo de la argumentacin
coincide con el campo correspondiente de este objeto.
Cuando haya terminado de escribir el mtodo equals, hgase tres preguntas: es simtrica?
Es transitiva? Es coherente?
Advertencias:
Siempre anular hashCode cuando se sobreescribe equals. No trates de ser demasiado
inteligente. No sustituya otro tipo de objeto en la declaracin de equals

Item9: Siembre sobreescribir el mtodo hashcode cuando se sobreescribe el mtodo equals

Siempre que sobreescribamos el mtodo equals, tambin tenemos que sobreescribir
tambin el mtodo hashCode. En el API de java para Object del mtodo hashCode se
especifica lo siguiente:
 Cuando este mtodo es invocado sobre el mismo objeto una o ms veces durante una
ejecucin en una aplicacin, el hashCode debe de ser consistente devolviendo
siempre el mismo valor, siempre que no se modifique el objeto. Este valor no tiene que
ser consistente entre ejecuciones distintas de la aplicacin.
Si dos objetos son iguales segun el mtodo equals, entonces el hashCode de los dos
objetos tiene que ser el mismo.
Si dos objetos no son iguales, el hashCode no tiene que ser necesariamente distinto,
pero es recomendable que lo sea.
Unos pasos para implementar un buen mtodo hashCode son:
Declaramos una variable entera y le asignamos un nmero, por
ejemplo result=17.
Para cada campo significativo de nuestro objeto, f:
o Calculamos en int c el valor de:
Tipo boolean: hacemos (f?1 : 0)
Tipos byte, char, short, o int: hacemos (int) f
Tipo Long: hacemos (int)(f^(f>>>32))
Tipo Float: hacemos Float.doubleToIntBits(f)
Tipo Double:
hacemos Double.doubleToLongBits(f) y (int)(f^(f>>
>32))
Si es una referencia a un objeto, llamamos al hashCode del
objeto. Si la referencia es nula, devolvemos un 0.
Si es un Array, utilizamos el mtodo Arrays.hashCode.
o Acumulamos el valor de c en result : result = 31 * result + c
Devolvemos el valor de result
Podemos excluir los campos que no comprobemos en el mtodo equals, pero
no es recomendable.
Item 10: Siempre sobreescribir toString
Veamos primero el mtodo toString(). El propsito de este mtodo es asociar a todo
objeto un texto representativo. Llamar a toString() sobre un objeto Integer producir
un resultado que es ms o menos obvio: nos devuelve el entero asociado, solo que en
forma de String. Pero qu ocurre cuando invocamos el mtodo sobre un objeto definido
por nosotros? Este sera el caso de una invocacin como System.out.println (Obtenemos
+ profesor1.toString() );. En este caso, el resultado que obtenemos es del tipo:
Obtenemos Profesor@1de9ac4. El mtodo efectivamente nos ha devuelto un String,
pero qu sentido tiene lo que nos ha devuelto? El resultado obtenido consta del nombre
de la clase seguido de una cadena extraa que representa la direccin de memoria en
que se encuentra el objeto. Este resultado en general es poco til por lo que el mtodo
toString() es un mtodo que habitualmente se sobreescribe al crear una clase. De hecho,
la mayora de las clases de la biblioteca estndar de Java sobreescriben el mtodo
toString(). Por otro lado, es frecuente que cuando un programador incluye mtodos como
imprimir, mostrar, listar, etc. de alguna manera dentro de ellos se realicen llamadas
al mtodo toString() para evitar la repeticin de cdigo. Tambin es frecuente que
toString() aparezca en tareas de depuracin ya que nos permite interpretar de forma
humana los objetos.
Independientemente de si usted decide especificar el formato, usted debe documentar
claramente sus intenciones. Si especifica el formato, debe hacerlo con precisin. por
ejemplo, aqu hay un mtodo toString para ir con la clase PhoneNumber en el Punto 9:

Item10: sobreescribir el mtodo clon

El mecanismo resultante es extralingstico: crea un objeto sin llamar a un constructor.
Copia de un objeto normalmente implicar la creacin de una nueva instancia de su clase,
pero puede requerir la copia de las estructuras de datos internos. No hay constructores
son llamados.
El principio general en juego aqu no es hacer que el cliente haga nada si la biblioteca
puede hacer por el cliente.
las funciones de mtodo clone como otro constructor; debe asegurarse de que no hace
ningn dao al objeto original y que establece correctamente invariantes en el clon. Este
es un problema fundamental: la arquitectura clon es incompatible con el uso normal de los
campos finales en referencia a objetos mutables, excepto en los casos en que los objetos
mutables pueden ser compartidos de forma segura entre un objeto y su clon. En resumen,
todas las clases que implementan Cloneable deben Override clon con un mtodo pblico
cuyo tipo de retorno es la propia clase. Este mtodo debe llamar primero a super.clone y
luego corregir los campos que deben ser corregidos. Por lo general, esto significa copiar
objetos mutables que conforman la "estructura profunda" interna del objeto que est siendo
clonado, y la sustitucin de las referencias del clon a estos objetos con referencias a las
copias. Si bien estas copias internos generalmente se pueden hacer llamando al clonar de
forma recursiva, esto no siempre es el mejor enfoque.

Tema 12: Considerar la implementacin Comparable

Comparable es una interfaz que slo contiene un mtodo: compareTo, que nos sirve para
ordenar los valores segn un orden natural, bien sea numrico o alfabtico. Si en Comparator
debamos especificar que tipo de comparacin queramos, y proporcionar un comparator, en
este caso vemos que eso no es necesario.
El mtodo compareTo debe seguir un contrato, o "reglas", similares a las del mtodo equals(
), que son las siguientes:
Tomando sgn(expresin) donde sgn devuelve -1, 0 o 1, segn el valor de la expresin sea
negativo, cero o positivo, y con explicaciones para los que no sean de ciencias
sgn(x.compareTo(y)) == -sgn(y.compareTo(x)). Si el primer objeto es menor que el
segundo, el segundo debe ser ms grande que el primero, y al revs. Y si el primero es
igual al segundo, el segundo es igual al primero.
(x.compareTo(y)>0 && y.compareTo(z)>0) implica que x.compareTo(z)>0. Si un objeto
es ms grande que un segundo objeto, y ste es ms grande que un tercero, entonces
el primero es ms grande que el tercero.
x.compareTo(y) == 0 implica que sgn(x.compareTo(z)) == sgn(y.compareTo(z)). Todos
los objetos que son iguales al compararlos deben dar el mismo resultado al
compararlos con un tercer objeto.
Una consecuencia de estas tres disposiciones es que la prueba impuesta por la igualdad un
mtodo compareTo debe obedecer las mismas restricciones impuestas por el contrato equals:
reflexividad, simetra y transitividad.
Por tanto, la misma advertencia se aplica: no hay manera de extender una clase instanciable
con un nuevo componente de valor, preservando el contrato compareTo, a menos que est
dispuesto a renunciar a los beneficios de la abstraccin orientada a objetos
CLASSES AND INTERFACES
Item 13: Minimizar la accesibilidad de clases y miembros
El factor ms importante que distingue un mdulo bien diseado de una mal diseado es el
grado en el que el mdulo de datos oculta su interior y otros detalles de la implementacin de
otros mdulos. El ocultamiento de informacin es importante por muchas razones, la mayora
de los cuales se derivan del hecho de que desacopla los mdulos que componen un sistema, lo
que les permite ser desarrollados, probados, optimizados, utilizan, entendidos, y se modifican
en forma aislada.
Esto acelera el desarrollo del sistema, porque los mdulos se pueden desarrollar en paralelo.
Facilita la carga de mantenimiento, ya que los mdulos se pueden entender con mayor rapidez
y depurar con poco temor de daar a otros mdulos.
privado-El miembro es accesible slo desde la clase de nivel superior, donde es declarado.
Paquete-privada-El miembro es accesible desde cualquier clase en el paquete donde se
declara. Tcnicamente conocido como el acceso por defecto, este es el nivel de acceso que se
obtiene si no se especifica ningn modificador de acceso.
protegido por El miembro es accesible desde las subclases de la clase donde es declarado y
de cualquier clase en el paquete donde se declara.
pblico-El miembro es accesible desde cualquier lugar.
Si un mtodo sobreescribe un mtodo de superclase, no se les permite tener un nivel de
acceso ms bajo en la subclase que lo hace en la superclase. Un caso especial de esta regla es
que si una clase implementa una interfaz, todos los mtodos de la clase, que tambin estn
presentes en la interfaz debe declararse pblico. Esto es as porque todos los miembros de una
interfaz son implcitamente pblica
Campos de instancia nunca deben ser pblicos. Si un campo de instancia es no final, o es una
referencia final a un objeto mutable, a continuacin, al hacer pblico campo, usted renuncia a
la posibilidad de limitar los valores que se pueden almacenar en el campo.
Despus de disear cuidadosamente una API pblica mnima, usted debe evitar que las clases
perdidas, interfaces, o miembros se conviertan en una parte de la API. Con la excepcin de los
campos finales pblicas estticas, clases pblicas no deben tener campos pblicos.
Asegrese de que los objetos referenciados por campos finales pblicas estticas son
inmutables.
Item 14: En las clases pblicas, utilizar mtodos de acceso, campos no pblicos
Si una clase pblica expone sus campos de datos, toda la esperanza de cambiar su
representacin se pierde, ya que el cdigo de cliente se puede distrib uir a lo largo y ancho.
En resumen, clases pblicas no deben exponer a campos mutables. Es menos daino, aunque
sigue siendo cuestionable, para las clases pblicas para exponer campos inmutables.
Es, sin embargo, a veces deseable para clases anidadas paquete-privada o privadas para
exponer campos, ya sea mutable o inmutable.
Tema 15: Minimizar mutabilidad
Una clase inmutable es simplemente una clase cuyas instancias no puede ser modificado. Toda
la informacin contenida en cada caso se proporciona cuando se crea y se fija durante la vida
til del objeto. Hay muchas buenas razones para ello: las clases inmutables son ms fciles de
disear, implementar y usar que las clases mutables. Ellos son menos propensos a error y son
ms seguros.
1. No proporcionan ningn mtodo que modifican el estado del objeto (conocido como
mutators).
2. Asegrese de que la clase no se puede ampliar. Esto evita que las subclases descuidadas o
maliciosas de comprometer el comportamiento inmutable de la clase por comportarse
como si el estado del objeto ha cambiado.
3. Hacer todos los campos final. Esto expresa claramente su intencin de una manera que se
hace cumplir por el sistema.
4. Hacer todos los campos privado. Esto evita que los clientes obtengan acceso a los objetos
mutables mencionados por los campos y modificar directamente estos objetos.
5. Garantizar el acceso exclusivo a cualquiera de los componentes mutables. Si su clase tiene
cualquier campo que se refieren a objetos mutables, garantizar que los clientes de la clase
no pueden obtener referencias a estos objetos.
Objetos inmutables son thread-safe inherentemente; que no requieren la sincronizacin. No
pueden ser corrompidos por mltiples hilos acceden ellos al mismo tiempo.
los objetos inmutables pueden ser compartidos libremente. Clases inmutables tienen la ventaja
de estar alentando los clientes a reutilizar las instancias existentes siempre que sea posible.
Una forma fcil de hacer esto es ofrecer constantes finales estticas pblicas de valores
utilizados con frecuencia
A consecuencia del hecho de que los objetos inmutables pueden ser compartidos libremente
es que usted nunca tendr que hacer copias de defensa. no es necesario y no debe
proporcionar un mtodo clon o copia constructor.
No slo se puede compartir objetos inmutables, pero usted puede compartir sus
interioridades.
Objetos inmutables hacen grandes bloques de construccin para otros objetos, ya sea mutable
o inmutable. Es mucho ms fcil de mantener las invariantes de un objeto complejo si sabe
que sus objetos componentes no cambiarn por debajo de ella.
La nica desventaja real de las clases inmutables es que requieren un objeto independiente
para cada valor distinto. La creacin de estos objetos puede ser costoso, especialmente si son
grandes. Recordemos que para garantizar la inmutabilidad, una clase no debe permitirse ser
subclase.
es imposible extender una clase que viene de otro paquete y que carece de un constructor
pblico o protegido (tema1)
Si secalcula el cdigo hash de la primera vez que se invoca y almacena en cach en caso se
invoca de nuevo. Esta tcnica, un ejemplo de inicializacin perezosa.
Hay algunas clases para las que la inmutabilidad es poco prctico. Si una clase no se puede
hacer inmutable, limitar su mutabilidad tanto como sea posible. Hacer que todos los cmapos
sean finales a menos ue haya una buena razn que no sea final
Item 16: A favor de la composicin sobre la herencia
La herencia es una poderosa manera de lograr la reutilizacin de cdigo, pero no siempre es la
mejor herramienta para el trabajo. Se utiliza de forma inapropiada, conduce al software frgil.
Es seguro utilizar la herencia dentro de un paquete, en donde la subclase y las
implementaciones superclase estn bajo el control de los mismos programadores. Tambin es
seguro de utilizar la herencia cuando las clases se extienden diseados y documentados para la
extensin especfica.
A diferencia de la invocacin de mtodos, herencia viola la encapsulacin. En otras palabras,
una subclase depende de los detalles de implementacin de su superclase para su correcto
funcionamiento
los problemas anteriores se derivan de Sustitucin de mtodos. Se podra pensar que es
seguro para extender una clase si se limita a aadir nuevos mtodos y se abstengan de
sobreescribir los mtodos existentes. Si bien este tipo de extensin es mucho ms seguro, no
es el mejor.
En lugar de extender una clase existente, dar a su nueva clase un campo privado que hace
referencia a una instancia de la clase existente. Este diseo se llama composicin porque la
clase existente se convierte en un componente de la nueva. Cada mtodo de instancia en la
nueva clase invoca el mtodo correspondiente en la instancia que figura de la clase existente y
devuelve los resultados. Esto se conoce como el reenvo, y los mtodos de la nueva clase se
conocen como mtodos de reenvo.
En resumen, la herencia es de gran alcance, pero es problemtico porque viola la
encapsulacin. Es apropiado slo cuando existe una relacin autntica entre el subtipo
subclase y la superclase. Incluso entonces, la herencia puede conducir a la fragilidad si la
subclase est en un paquete diferente de la superclase y la superclase no est diseado para la
herencia. Para evitar esta fragilidad, utilice composicin y el reenvo en vez de la herencia,
sobre todo si una interfaz adecuada para implementar un wrapper clase existe. No slo son
clases contenedoras ms robustas que las subclases, sino que tambin son ms poderosos.
Item 17: Disear y Documentar la herencia o prohibirla
En primer lugar, la clase debe documentar con precisin los efectos de anular cualquier
mtodo. En otras palabras, la clase debe documentar su propia utilizacin de mtodos
reemplazables.
Por convencin, un mtodo que invoca mtodos reemplazables contiene una descripcin de
estas invocaciones al final de su comentario documentacin.
Los constructores no deben invocar mtodos sobreescritsso, directa o indirectamente.
Por ahora debera ser evidente que el diseo de una clase para la herencia pone limitaciones
sustanciales en la clase.
La mejor solucin a este problema es prohibir subclases en las clases que no estn diseados y
documentados ser subclase de manera segura.
Artculo 18: Prefiero interfaces a las clases abstractas
El lenguaje de programacin Java proporciona dos mecanismos para la definicin de un tipo de
que permite mltiples implementaciones: interfaces y clases abstractas.
Las clases abstractas permiten contener implementaciones para algunos mtodos mientras
que las interfaces no.

Clases existentes pueden ser adaptados fcilmentepara implementar una nueva

interfaz. Todo lo que tienes que hacer es agregar los mtodos necesarios sino existen
todava
Interfaces son ideales para definir mixins. En trminos generales, un mixin es un tipo que una
clase puede implementar, adems de su "tipo primario" para declarar que ofrece un
comportamiento opcional.
Las interfaces permiten la construccin de marcos de tipo no jerrquicas.
Tipo jerarquas son excelentes para organizar algunas cosas, pero otras cosas no caen
perfectamente en una jerarqua rgida.
Interfaces permiten seguras y potentes mejoras de funcionalidad a travs del idioma clase
contenedora,

Es mucho ms fcil evolucionar una clase abstractade una interfaz.

Interfaces pblicas, por lo tanto, deben ser diseados cuidadosamente. Una vez que una
interfaz es liberado y ampliamente implementado, es casi imposible cambiarlo.
Para resumir, una interfaz es generalmente la mejor manera para definir un tipo que permite
mltiples implementaciones. Una excepcin a esta regla es el caso en el que se considera ms
importante que la flexibilidad y potencia la facilidad de evolucin. En estas circunstancias, se
debe utilizar una clase abstracta para definir el tipo, pero slo si usted entiende y puede
aceptar las limitaciones. Si exporta una interfaz no trivial, usted debe considerar seriamente
proporcionar una implementacin del esqueleto para ir con ella.
Por ltimo, debe disear todas sus interfaces pblicas con el mximo cuidado y probarlos a
fondo por escrito mltiples implementaciones.
Tema 19: Use las interfaces slo para definir los tipos
Cuando una clase implementa una interfaz, la interfaz sirve como un tipo que se puede utilizar
para referirse a instancias de la clase.
En resumen, las interfaces slo deben usarse para definir tipos. No deben ser usados para
exportar constantes.
Tema20: preferir jerarqa de clases a clases etiquetadas
En resumen, etiquetadas clases rara vez son apropiadas. Si usted est tentado a escribir una
clase con un campo de etiqueta explcita, piense si la etiqueta podra ser eliminado y la clase
reemplazado por una jerarqua. Cuando se encuentre con una clase existente con un campo de
etiqueta, considere refactorizacin en una jerarqua.
Artculo 21: Usar objetos de funcin para representar las estrategias
En resumen, un uso principal de los punteros de funcin es implementar el patrn Estrategia.
Para implementar este patrn en Java, declarar una interfaz para representar la estrategia, y
una clase que implementa esta interfaz para cada estrategia concreta.
Cuando se utiliza una estrategia concreta slo una vez, tpicamente se declara y crea una
instancia como una clase annima. Cuando una estrategia concreta est diseado para el uso
repetido, se implementa generalmente como una clase de miembro esttico privado y exporta
en un campo public static final cuyo tipo es la interfaz de estrategia.
genricos
Artculo 23: No utilice tipos primas en nuevo cdigo
Artculo 24: Eliminar las advertencias sin marcar
Artculo 25: Prefiero listas a matrices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Artculo 26: Favorecer a tipos genricos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Artculo 27: Favorecer a mtodos genricos. . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Artculo 28: Uso limitado comodines para aumentar la flexibilidad de la API. . . . . 134
Artculo 29: Considere typesafe contenedores heterogneos. . . . . . . . . . 142
Enumeraciones y Anotaciones
Artculo 30: Usar enumeraciones en lugar de int constantes
Artculo 31: Utilice campos de instancia en lugar de los ordinales. . . . . . . . . . . . . . . 158
Artculo 32: El uso EnumSet lugar de campos de bits. . . . . . . . . . . . . . . . . . . 159
Artculo 33: El uso EnumMap lugar de indexacin ordinal. . . . . . . . . . . . . 161
Artculo 34: Emular enumeraciones extensibles con interfaces. . . . . . . . . . . . 165
Artculo 35: Prefiero anotaciones a los patrones de nombres. . . . . . . . . . . . . . . 169
Artculo 36: usar consistentemente la anotacin de anulacin. . . . . . . . . . . . 176
Artculo 37: Utilice las interfaces de marcador para definir tipos. . . . . . . . . . . . . . . 179

7 Mtodos
Artculo 38: Compruebe los parmetros de validez. . . . . . . . . . . . . . . . . . . . . 181
Artculo 39: Haga copias de defensa cuando sea necesario. . . . . . . . . . . . . . . . 184
Artculo 40: Mtodo de Diseo Firmas cuidado. . . . . . . . . . . . . . . . . 189
Artculo 42: El uso varargs juiciosamente. . . . . . . . . . . . . . . . . . . . . . . . . . 197
Artculo 43: Regreso matrices vacas o colecciones, no nulos. . . . . . . . . 201
Artculo 44: Escribir comentarios de documentacin para todos los elementos expuestos API
8 Programacin general
Artculo 45: Reducir al mnimo el alcance de las variables locales
Artculo 46: Prefiero for-each bucles a lo tradicional bucles. . . . . . . . . 212
Artculo 47: Conocer y utilizar las bibliotecas. . . . . . . . . . . . . . . . . . . . . . . 215
Artculo 48: Evitar el flotador y el doble si se requieren respuestas exactas
Artculo 49: Prefiero tipos primitivos a primitivas en caja. . . . . . . . . . . 221
Artculo 50: Evite cadenas donde otros tipos son ms apropiadas. . 224
Artculo 51: Cuidado con el rendimiento de la concatenacin de cadenas. . . . . . 227
Artculo 52: Consulte objetos por sus interfaces. . . . . . . . . . . . . . . . . 228
Artculo 53: Prefiero interfaces a las la reflexin. . . . . . . . . . . . . . . . . . . . . 230
Artculo 54: Use mtodos nativos con criterio. . . . . . . . . . . . . . . . . . . . 233
Artculo 55: Optimizar juiciosamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Artculo 56: Se adhieren a las convenciones de nombres generalmente aceptados.
excepciones
Artculo 57: Utilice excepciones slo para condiciones excepcionales. . . . . . . 241
Artculo 58: Uso comprueba excepciones para condiciones recuperables y excepciones de
tiempo de ejecucin de errores de programacin
Artculo 59: Evite el uso innecesario de excepciones comprobadas. . . . . . . . 246
Artculo 60: Favorecer el uso de excepciones estndar. . . . . . . . . . . . . . . . 248
Artculo 61: Lance excepciones apropiadas a la abstraccin. . . . . . . 250
Artculo 62: Documentar todas las excepciones lanzadas por cada mtodo. . . . . . 252
Artculo 63: Incluir informacin fracaso de captura en los mensajes detalle
Artculo 64: Luchar por la atomicidad fracaso. . . . . . . . . . . . . . . . . . . . . . . 256
Artculo 65: No ignore excepciones. . . . . . . . . . . . . . . . . . . . . . . . . 258
Concurrencia
Artculo 66: Sincronizar el acceso a los datos mutables compartidos. . . . . . . . . . . 259
Tema 67: Evitar la sincronizacin excesiva. . . . . . . . . . . . . . . . . . 265
Artculo 68: Prefiero ejecutores y tareas a hilos. . . . . . . . . . . . . . . . 271
Artculo 69: Prefiero utilidades de concurrencia que esperar y notificar. . . . . . . 273
Artculo 70: Documento de seguridad hilo. . . . . . . . . . . . . . . . . . . . . . . . . . 278
Artculo 71: Utilice la inicializacin perezosa juiciosamente. . . . . . . . . . . . . . . . . . 282
Artculo 72: No depende del planificador de hilos. . . . . . . . . . . . . . . 286
Artculo 73: Evite grupos de hilos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Publicacin por entregas
Artculo 74: Implementar Serializable juiciosamente. . . . . . . . . . . . . . . 289
Artculo 75: Considere el uso de un formulario serializado personalizado.
Artculo 76: Escribir mtodos readObject defensivamente. . . . . . . . . . . . . 302
Artculo 77: Para el control de instancias, prefieren tipos de enumeracin a readResolve
Artculo 78: Considere proxies de serializacin en lugar de instancias serializados.