1. La primera letra del nombre de la clase debe estar en mayúscula. La primera letra de los campos, métodos y objetos (identificadores) debe estar en minúscula. Como ocurre con todos los identificadores, todas las palabras contenidas en él deben estar juntas, con la primera letra de la palabra intermedia en mayúscula. Por ejemplo:
Copie el código de la siguiente manera: ThisIsAClassName
este es el método o el nombre del campo
Si aparece un carácter inicializador constante en la definición, escriba en mayúscula todas las letras en el identificador de tipo básico final estático. Esto los marcará como constantes en tiempo de compilación.
Los paquetes Java son un caso especial: todos están en minúsculas, incluso las palabras del medio. Para los nombres de extensión de nombres de dominio, como com, org, net o edu, etc., todos deben estar en minúsculas (esta es también una de las diferencias entre Java 1.1 y Java 1.2).
2. Al crear una clase para uso general, adopte la "forma clásica" e incluya definiciones de los siguientes elementos:
Copie el código de código de la siguiente manera:
es igual()
código hash()
a cadena()
clonar()(implementar clonable)
implementar serializable
3. Para cada clase que cree, considere colocar un main(), que contiene el código para probar esa clase. Para usar clases de un proyecto, no es necesario eliminar el código de prueba. Si se realizan cambios de cualquier tipo, es fácil volver a realizar las pruebas. El código también sirve como ejemplo de cómo utilizar las clases.
4. El método debe diseñarse en una unidad funcional breve, que pueda usarse para describir e implementar una parte de interfaz de clase discontinua. Idealmente, el enfoque debería ser conciso y directo. Si el largo es grande, considera dividirlo en trozos más cortos de alguna manera. Hacer esto también facilita la reutilización del código dentro de una clase (a veces, los métodos deben ser muy grandes, pero aun así deberían hacer lo mismo).
5. Al diseñar una clase, póngase en el lugar del programador cliente (el método de uso de la clase debe ser muy claro). Luego, póngase en el lugar de la persona que administra el código (anticipe qué tipos de cambios es probable que se realicen y piense en formas de simplificarlos).
6. Haz que la clase sea lo más corta y concisa posible, y solo resuelve un problema específico. Aquí hay algunas sugerencias para el diseño de clases:
1. Una declaración de cambio compleja: considere usar el mecanismo "polimórfico"
2. Una gran cantidad de métodos implican operaciones con tipos muy diferentes: considere usar varias clases para implementarlas por separado.
3. Muchas variables miembro tienen características muy diferentes: considere usar varias clases
7. Haz que todo sea lo más "privado" posible. Puede hacer que una parte de la biblioteca sea "pública" (un método, una clase, un campo, etc.) para que nunca pueda eliminarse. Si lo fuerza a salir, puede destruir el código existente de otras personas, obligándolos a reescribirlo y diseñarlo. Si solo publica lo que debe publicar, puede cambiar cualquier otra cosa. En entornos de subprocesos múltiples, la privacidad es un factor particularmente importante. Sólo los campos privados pueden protegerse contra el uso no sincronizado.
8. Tenga cuidado con el “síndrome del objeto gigante”. Para algunos principiantes que están acostumbrados al pensamiento de programación secuencial y son nuevos en el campo de la programación orientada a objetos, a menudo les gusta escribir primero un programa de ejecución secuencial y luego incrustarlo en uno o dos objetos grandes. Según los principios de programación, los objetos deben expresar el concepto de la aplicación, no la aplicación en sí.
9. Si tienes que hacer alguna programación desagradable, al menos deberías poner el código dentro de una clase.
10. Siempre que descubra que las clases están muy integradas, debe considerar si utilizar clases internas para mejorar el trabajo de codificación y mantenimiento (consulte "Mejora del código con clases internas" en el Capítulo 14, Sección 14.1.2).
11. Agregue comentarios con el mayor cuidado posible y utilice la sintaxis del documento de comentarios javadoc para generar su propia documentación del programa.
12. Evite el uso de "números mágicos". Es difícil que estos números encajen bien con el código. Si necesita modificarlo en el futuro, sin duda se convertirá en una pesadilla, porque no tiene idea de si "100" se refiere al "tamaño de la matriz" o a "algo completamente distinto". Por lo tanto, debemos crear una constante, darle un nombre convincente y descriptivo y utilizar identificadores de constantes en todo el programa. Esto hace que el programa sea más fácil de entender y mantener.
13. Cuando se trata de constructores y excepciones, normalmente querrás volver a lanzar cualquier excepción detectada en el constructor si provocó que fallara la creación de ese objeto. De esta manera la persona que llama no seguirá pensando ciegamente que el objeto se ha creado correctamente.
14. Después de que el programador cliente haya terminado de usar el objeto, si su clase requiere algún trabajo de limpieza, considere colocar el código de limpieza en un método bien definido, usando un nombre como cleanup() para indicar claramente su uso. Además, se puede colocar una bandera booleana dentro de la clase para indicar si el objeto se ha borrado. En el método finalize() de la clase, asegúrese de que el objeto se haya borrado y que una clase que hereda de RuntimeException se haya descartado (si aún no lo ha hecho), lo que indica un error de programación. Antes de tomar una solución como esta, asegúrese de que finalize() funcione en su sistema (es posible que deba llamar a System.runFinalizersOnExit(true) para garantizar este comportamiento).
15. En un ámbito específico, si un objeto debe borrarse (no procesarse mediante el mecanismo de recolección de basura), utilice el siguiente método: inicialice el objeto, si tiene éxito, ingrese inmediatamente un bloque de prueba que contenga una cláusula finalmente para iniciar el trabajo de limpieza; .
16. Si necesita anular (cancelar) finalize() durante el proceso de inicialización, recuerde llamar a super.finalize() (si el Objeto pertenece a nuestra superclase directa, esto no es necesario). En el proceso de anular finalize(), la llamada a super.finalize() debe ser la última acción, no la primera, para garantizar que los componentes de la clase base sigan siendo válidos cuando sean necesarios.
17. Al crear colecciones de objetos de tamaño fijo, transfiéralas a una matriz (especialmente si planea devolver esta colección desde un método). De esta manera, podemos disfrutar de los beneficios de la verificación del tipo de matriz en tiempo de compilación. Además, es posible que el destinatario de la matriz no necesite "transmitir" el objeto a la matriz para poder utilizarlo.
18. Intente utilizar interfaces en lugar de clases abstractas. Si sabes que algo será una clase base, tu primera opción debería ser convertirlo en una interfaz. Solo cuando tenga que usar definiciones de métodos o variables miembro, deberá convertirlo en una clase abstracta. Una interfaz básicamente describe lo que el cliente quiere hacer, mientras que una clase está dedicada (o permite) detalles de implementación específicos.
19. Dentro del constructor, haga sólo el trabajo necesario para poner el objeto en el estado correcto. Siempre que sea posible, evite llamar a otros métodos, ya que esos métodos pueden ser anulados o cancelados por otros, produciendo resultados impredecibles durante el proceso de construcción (consulte el Capítulo 7 para obtener más detalles).
20. Los objetos no deberían simplemente contener algunos datos; su comportamiento también debería estar bien definido.
21. Al crear una nueva clase basada en una clase existente, primero seleccione "Nuevo" o "Crear". Esta cuestión sólo debe considerarse si se deben heredar sus propios requisitos de diseño. Si se utiliza la herencia donde se permite la nueva creación, todo el diseño se vuelve innecesariamente complejo.
22. Utilice la herencia y la cobertura de métodos para expresar la diferencia entre comportamientos y utilice campos para expresar la diferencia entre estados. Un ejemplo muy extremo es representar colores a través de la herencia de diferentes clases, lo que definitivamente debe evitarse: use un campo de "color" directamente.
23. Para evitar problemas al programar, asegúrese de que cada nombre corresponda solo a una clase dondequiera que apunte su ruta de clases. De lo contrario, el compilador podría encontrar primero otra clase con el mismo nombre y generar un mensaje de error. Si sospecha que ha encontrado un problema de ruta de clases, intente buscar un archivo .class con el mismo nombre en cada punto inicial de la ruta de clases.
24. Cuando se utilizan "adaptadores" de eventos en Java 1.1 AWT, es particularmente fácil encontrar una trampa. Si se anula un método adaptador y el método de ortografía no es particularmente particular, el resultado final será agregar un nuevo método en lugar de anular el método existente. Sin embargo, dado que esto es perfectamente legal, no recibirá ningún mensaje de error del compilador o del sistema de ejecución, pero su código simplemente se comportará incorrectamente.
25. Utilice soluciones de diseño razonables para eliminar las "pseudofunciones". Es decir, si solo necesita crear un objeto de la clase, no se limite a la aplicación de antemano y agregue un comentario "generar solo uno de ellos". Considere encapsularlo en un formato de "hijo único". Si tiene mucho código disperso en el programa principal que se utiliza para crear sus propios objetos, considere adoptar una solución creativa para encapsular este código.
26. Tenga cuidado con la "parálisis por análisis". Recuerde, pase lo que pase, debe comprender el estado de todo el proyecto de antemano y luego examinar los detalles. Debido a que comprende la situación general, puede reconocer rápidamente algunos factores desconocidos y evitar caer en una "lógica muerta" al examinar los detalles.
27. Tenga cuidado con la "optimización prematura". Haga que se ejecute primero, piense en hacerlo más rápido más adelante, pero optimice solo si es necesario y si se demuestra que hay un cuello de botella en el rendimiento en alguna parte del código. A menos que utilice herramientas especializadas para analizar los cuellos de botella, probablemente esté perdiendo el tiempo. El costo implícito de las mejoras en el rendimiento es que el código se vuelve más difícil de entender y de mantener.
28. Recuerda que pasas mucho más tiempo leyendo código que escribiéndolo. Un diseño claro da como resultado un programa fácil de entender, pero los comentarios, las explicaciones detalladas y algunos ejemplos suelen ser invaluables. Son muy importantes, tanto para ti como para quienes te siguen. Si todavía lo duda, imagine su frustración al intentar encontrar información útil en la documentación de Java en línea, y puede que se convenza.
29. Si cree que ha realizado un buen análisis, diseño o implementación, cambie ligeramente su perspectiva de pensamiento. Intente invitar a algunas personas externas, no necesariamente expertos, sino personas de otras partes de la empresa. Pídales que observen su trabajo con ojos completamente nuevos y vean si pueden detectar problemas que usted no veía. Al adoptar este método, a menudo podemos identificar algunos problemas clave en la etapa más adecuada para la modificación y evitar la pérdida de dinero y energía causada por resolver problemas después del lanzamiento del producto.
30. Un buen diseño puede generar mayores beneficios. En resumen, a menudo lleva mucho tiempo encontrar la solución más adecuada a un problema determinado. Pero una vez que encuentre el método correcto, su trabajo futuro será mucho más fácil y no tendrá que soportar horas, días o meses de dolorosa lucha. Nuestro arduo trabajo traerá las mayores recompensas (incluso inconmensurables). Y como puse mucho esfuerzo en ello, finalmente obtuve un excelente plan de diseño, y la emoción del éxito también es emocionante. Resista la tentación de apresurarse en el trabajo, que a menudo no vale la pena.