¿Cómo hacer un programa java?
ThisIsAClassName
thisIsMethodOrFieldName
Si aparece un carácter inicializador constante en la definición, todas las letras del identificador de tipo primitivo final estático deben escribirse en mayúscula. Esto los marca 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. Las extensiones de dominio como com, org, net o edu también están en minúsculas (esta es 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 la definición de los siguientes elementos: clone() (implementar Cloneable)
implementar Serializable
(3) Para cada clase que cree, considere colocar un main() que contenga código que pruebe la clase. Para utilizar las clases en el proyecto, no necesitamos eliminar el código de prueba. También es fácil volver a realizar las pruebas si algo cambia. El código también se puede utilizar como ejemplo de cómo utilizar las clases.
(4) Los métodos deben diseñarse como unidades funcionales breves que describan e implementen partes discretas de la interfaz de clase. Idealmente, el enfoque debería ser conciso y directo. Si un método es muy largo, considere dividirlo de alguna manera en métodos más cortos. Esto también facilita la reutilización del código dentro de una clase (a veces tiene que haber muchos métodos, pero aun así solo deberían hacer lo mismo). (5) Al diseñar una clase, póngase en el lugar del programador cliente (que debe saber exactamente cómo usar la clase). Luego, póngase en el lugar de las personas que administran el código (anticipe las modificaciones que podrían surgir y piense en formas de facilitarlas).
(6) Mantenga las clases lo más cortas y compactas posible y resuelva solo un problema específico. Aquí hay algunas sugerencias para el diseño de clases:
■ Declaraciones de cambio complejas: considere usar mecanismos de "polimorfismo"
■ Gran cantidad de métodos que involucran diferentes tipos de operaciones: considere usar múltiples clases para implementar por separado
■ Gran cantidad de variables miembro con diferentes características: considere usar varias clases para implementarlas por separado.
(7) "Privado" todo tanto como sea posible: privatizar parte de la biblioteca (métodos, clases o campos, etc.). Partes de una biblioteca (métodos, clases, campos, etc.) pueden hacerse "públicas" y nunca pueden eliminarse. Si fuerza la eliminación, puede romper el código existente de otras personas y tendrán que reescribirlo y rediseñarlo. Si publica solo lo que debe publicarse, puede modificar otros contenidos de forma segura y audaz. En entornos multiproceso, la privacidad es un factor especialmente importante: sólo los campos privados están protegidos cuando se utilizan de forma asincrónica.
(8) Cuidado con el "síndrome del objeto gigante". A los novatos en la programación secuencial que son nuevos en la programación orientada a objetos a menudo les gusta escribir un programa que se ejecute secuencialmente y luego lo incorpore en uno o dos objetos enormes. Según los principios de programación, los objetos deben expresar los conceptos de la aplicación, no la aplicación en sí.
(9) Si debes hacer alguna programación menos elegante, al menos deberías poner el código en una clase.
(10) Si encuentra que las clases están muy estrechamente acopladas, entonces debe considerar si usar clases internas para mejorar la codificación y el mantenimiento (consulte "Usar clases internas para mejorar" en el Capítulo 14, Sección 14.1 .2 código").
(11) Comente tanto como sea posible y genere su propia documentación del programa utilizando la sintaxis de documentación de comentarios de javadoc.
(12) Evite el uso de "números mágicos" porque son difíciles de incorporar a su código. Si necesita modificarlo más tarde, es una pesadilla porque no sabe si "100" se refiere al "tamaño de la matriz" o a "algo completamente distinto". Por lo tanto, deberíamos crear una constante, darle un nombre descriptivo y convincente y utilizar identificadores de constantes en todo el programa. Esto hará que el programa sea más fácil de entender y mantener.
(13) Cuando se trata de constructores y excepciones, si una excepción detectada en el constructor hace que falle la creación del objeto, entonces la excepción generalmente debe volver a lanzarse. De esta manera, la persona que llama no asume que el objeto se ha creado correctamente y continúa a ciegas.
(14) Si su clase requiere algún trabajo de limpieza después de que el programador cliente haya terminado de usar el objeto, considere colocar el código de limpieza en un método bien definido llamado cleanup () para indicar claramente su propósito. Además de esto, puede colocar una bandera booleana en 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 limpiado y que la 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 ejecutar un programa como este, asegúrese de que finalize () funcione correctamente en su sistema (es posible que deba llamar a System.runFinalizersonExit(true) para garantizar este comportamiento).
(15) Si el objeto debe borrarse en un ámbito específico (en lugar de a través del mecanismo de recolección de basura), haga lo siguiente: inicialice el objeto, si tiene éxito, ingrese inmediatamente el bloque de código de prueba con finalmente; cláusula, comience a borrar.
(16) Si necesita anular (cancelar) finalize() durante la inicialización, recuerde llamar a super.finalize() (no es necesario si el objeto pertenece a nuestra superclase inmediata). Al anular finalize(), llamar a super.finalize() debe ser la última operación, no la primera, para garantizar que el componente de la clase base siga siendo válido cuando sea necesario.
(17) Al crear colecciones de objetos de tamaño fijo, muévalas a matrices (especialmente si devuelves la colección desde un método). De esta manera podemos escribir y verificar la matriz en tiempo de compilación. Además, es posible que los destinatarios de las matrices no necesiten "estilizar" los objetos como matrices para poder utilizarlos.
(18) Intente utilizar interfaces en lugar de clases abstractas. Si se sabe que un objeto puede convertirse en una clase base, primero se debe convertir en una interfaz. Debe convertirla en una clase abstracta sólo si debe utilizar definiciones de métodos o variables miembro. Las interfaces describen principalmente lo que los clientes quieren hacer, mientras que las clases están especializadas (o permiten) detalles de implementación específicos.
(19) En el constructor, realice solo aquellas operaciones necesarias para establecer el objeto en el estado correcto. Evite llamar a otros métodos siempre que sea posible, ya que estos métodos pueden ser anulados o cancelados por otros métodos, produciendo resultados impredecibles durante el proceso de construcción (consulte el Capítulo 7 para obtener más detalles).
(20) Los objetos no deben simplemente contener algunos datos, su comportamiento también debe estar claramente definido.
(21) Al crear una nueva clase basada en una clase existente, seleccione Nuevo o Crear primero. Debe considerar este enfoque sólo si su diseño requiere herencia. Si utiliza la herencia donde permite la creación de nuevas clases, todo el diseño se vuelve innecesariamente complejo.
(22) La herencia y la sobrecarga de métodos se utilizan para expresar diferencias entre comportamientos, mientras que los campos se utilizan para expresar diferencias entre estados. Un ejemplo muy extremo es representar el color heredando de diferentes clases, lo cual no se puede evitar en absoluto: basta con utilizar un campo de "color".
(23) Para evitar problemas de programación, asegúrese de que cada nombre corresponda a una sola clase, sin importar hacia dónde apunte su classpath. De lo contrario, el compilador puede encontrar primero otra clase con el mismo nombre y generar un mensaje de error. Si sospecha que tiene un problema de classpath, intente buscar un archivo .class con el mismo nombre en cada punto inicial de la classpath.
(24) Hay un problema especial al usar "adaptadores" de eventos en Java 1.1 AWT. Si anula uno de los métodos del adaptador y no lo explica bien, terminará agregando un nuevo método en lugar de anular el método existente. Sin embargo, dado que esto es perfectamente legal, ni el compilador ni el sistema de ejecución mostrarán un error, simplemente el código no se ejecutará correctamente.
(25) Eliminar las “pseudofunciones” mediante soluciones de diseño sonoro.
Es decir, si solo necesita crear un objeto de clase, no se limite a la aplicación pasando la anotación "generar solo uno". Puede considerar encapsularlo como una "única subclase". Si tiene mucho código disperso en el programa principal que crea sus propios objetos, considere una solución creativa para encapsular este código.
(26) Cuidado con la "parálisis por análisis". Recuerde, pase lo que pase, debe conocer todo el proyecto de antemano antes de profundizar en los detalles. Al comprender el panorama general, puede identificar rápidamente factores que desconoce y evitar caer en una "lógica muerta" al examinar los detalles.
(27) Tenga cuidado con la "optimización prematura". Primero ejecute el programa y luego piense en mejorar la velocidad, pero optimice solo cuando sea necesario y solo cuando encuentre cuellos de botella en el rendimiento en ciertas partes del código. A menos que utilice herramientas especializadas para analizar los cuellos de botella, probablemente esté perdiendo el tiempo. El costo oculto de un mayor rendimiento es que su propio código se vuelve más difícil de entender y mantener.
(28) Recuerde, leer el código lleva más tiempo que escribirlo. Un diseño bien pensado produce programas fáciles de entender, pero los comentarios, las explicaciones detalladas y algunos ejemplos suelen ser invaluables. Son importantes tanto para usted como para quienes vendrán después de usted. Si todavía es escéptico, recuerde las frustraciones que encontró al intentar encontrar información útil en la documentación de Java en línea, y puede que esto le convenza.
(29) Si crees que has hecho un buen trabajo en análisis, diseño o implementación, cambia tu perspectiva. Intente invitar a algunas personas externas, no necesariamente expertos, sino personas de otras partes de la organización. Pídales que observen su trabajo con ojos nuevos y vean si pueden detectar problemas que antes pasaba por alto. Con este enfoque, a menudo se pueden encontrar problemas críticos en la etapa más adecuada para la modificación y evitar la pérdida de dinero y esfuerzo al solucionar los problemas después del lanzamiento del producto.
(30) Un buen diseño puede maximizar los beneficios. En resumen, a menudo lleva mucho tiempo encontrar la solución más adecuada a un problema determinado. Pero una vez que encuentre la solución adecuada, será mucho más fácil en el futuro en lugar de tener que luchar durante horas, días o meses. Nuestro arduo trabajo traerá las mayores recompensas (incluso recompensas inconmensurables). La emoción del éxito es tentadora, porque pusiste tu corazón y tu alma en ello y finalmente obtuviste una gran solución de diseño. Resiste la tentación de apresurarte: eso muchas veces no termina bien.