Solicitar un resumen del desarrollo de un sistema de gestión de bibliotecas (desde la perspectiva de un diseñador)

Ha pasado casi un mes desde que comenzaron las clases. La primera vez trabajé en un proyecto pequeño: un sistema de gestión de bibliotecas. Es muy pequeño, pero aprendí mucho con él, no solo entregando tareas, sino consolidando conocimientos y sentando una base sólida. uno. Estándares de programación Estándares de programación Aquí es donde más me siento. Los proyectos de desarrollo corporativo de hoy ya no se pueden realizar solos. Requieren división del trabajo y trabajo en equipo. Los miembros del equipo deben leer el código de los demás. Además, una vez desarrollado un sistema, no es necesario utilizarlo una vez, sino que se debe actualizar y mantener continuamente para satisfacer las necesidades cambiantes de los usuarios. En este proceso, es posible que no lo complete usted, sino otros, lo que requiere que cualquiera lea y comprenda su código de forma independiente, por lo que el valor de los estándares de programación se refleja naturalmente en este momento. Por este motivo, el código debe escribirse de conformidad con los estándares y especificaciones de la industria. Por ejemplo, los comentarios en el documento deben entenderse claramente y las funciones, nombres, parámetros y valores de retorno de clases y métodos deben resumirse en detalle de la siguiente manera: (1). El nombre del paquete debe reflejar las funciones del sistema que desea desarrollar y el nombre del paquete debe estar claramente dividido en cuatro niveles. Generalmente, el nombre de dominio de la empresa debe escribirse al revés. En otras palabras, este sistema de gestión de bibliotecas puede utilizar el nombre de dominio de nuestra escuela cn.edu.hevttc en su conjunto, más el nombre del sistema book, seguido de los nombres de cada capa, como cn.edu.hevttc.book..ui ( capa de presentación) y cn.edu.hevttc.book.service (capa de servicio). Cn.edu.hevttc.book.dao (capa de persistencia), cn.edu.hevttc.book.domain (este paquete coloca principalmente clases de entidad y tablas de mapeo en la base de datos), también puede tener un paquete: cn.edu. TTC .book . util, que contiene clases de herramientas que pueden ser utilizadas por todo el sistema. Tenga en cuenta también que los nombres de los paquetes deben estar en minúsculas. (2) Denominación de clases, métodos, variables y controles 1. Los nombres de las clases deben ser sustantivos, no verbos, con la primera letra en mayúscula y las palabras separadas por la primera letra en mayúscula. Por ejemplo, esta es una interfaz de capa de servicio, servicio de libro de interfaz pública {. Los métodos generalmente se nombran con la primera palabra como un verbo seguido de un sustantivo. El verbo debe estar en minúscula y la primera letra del sustantivo debe estar en mayúscula. Por ejemplo: cadena pública getNextID(){

............} 3. El nombre de la variable suele ser el mismo que el nombre del método. 4. En VE, la denominación de un control generalmente precede al tipo de control y al significado de la función a realizar. Por ejemplo, denominación de etiqueta: lblResults denominación de botón: btnSubmit puede hacer referencia a la convención de nomenclatura de control. neto. Nota: En términos generales, no importa qué aspecto se nombre, debe reflejar el significado de la función que desea completar, de modo que cualquier programador que vea su código pueda "conocer su significado por su nombre". Esto es lo más importante, refleja directamente la legibilidad del código y es una parte integral de la especificación de programación. (3) Las notas de las preguntas anotadas deben entenderse en detalle. La calidad de los comentarios de la documentación se refleja directamente en la documentación de la API, porque otros quieren comprender las funciones de las clases de código, los métodos y las interfaces de la documentación de la API. Al comienzo de todo el documento, haga una declaración sobre derechos de autor, tiempo, etc. , y use /*…………………………………………*/ para completar la descripción de una función al comienzo de la clase, indicando qué tipo de función desea completar en esta clase; el método debe explicar la función, los parámetros, los valores de retorno y las posibles excepciones, los comentarios sobre las variables deben explicar el significado de las variables, los comentarios de la documentación deben colocarse en /* *.... */, solo se generarán aquellos colocados dentro de la documentación API. Nota: Si desea escribir un buen comentario, la forma más sencilla es consultar el código de la empresa Sun, porque tiene más autoridad. 1. Estructura jerárquica del diseño del sistema (estructura de cuatro capas) La calidad del diseño de un sistema está directamente relacionada con la durabilidad del sistema, porque el criterio para medir un buen sistema es si puede satisfacer las necesidades cambiantes de los usuarios y si puede cumplir con los requisitos de reutilización y escalabilidad. Para lograr este objetivo, las clases con las mismas funciones deben colocarse en el mismo paquete, es decir, en la misma capa.

Estas capas no se llaman directamente, sino a través de interfaces, pero pueden estar estrechamente relacionadas entre sí para lograr una alta cohesión y un bajo acoplamiento. Esta vez tengo una comprensión más profunda de la importancia de la estructura de cuatro capas. Era la primera vez que lo jugaba libremente y, justo después de completar la función, las capas estaban demasiado conectadas y todas estaban apretadas. "Si cambias este lugar, tendrás que cambiar ese lugar nuevamente. La carga de trabajo de mantener este tipo de código es enorme. La estructura de cuatro capas puede resolver este problema muy bien. Entonces, lo que aprendí es que debes hacer un buen diseño. antes de escribir código El punto clave es que "afilar un cuchillo no significa perder tiempo cortando madera", un buen diseño puede obtener el doble de resultado con la mitad de esfuerzo 2. Cuando las expresiones regulares están involucradas en la verificación en el sistema, básicamente. Usé el método de bucle al principio, y el código era para..., si... De lo contrario... a través de la comunicación, descubrí un nuevo método, que son las expresiones regulares. Se entiende que las expresiones regulares se usan especialmente para. La verificación del uso de expresiones regulares puede reducir en gran medida la cantidad de código y es la única dificultad para escribir expresiones regulares. Si escribes bien, todo estará bien, pero generalmente es difícil. Hay muchas cosas que no comprende y no es fácil entenderlas todas, por lo que a veces puede tomarlas prestadas. Es mejor utilizar los resultados ya preparados de otras personas. Por ejemplo, la verificación de fecha no se puede entender en tres o dos días. Puede copiarlo en línea, pero quería aprender más sobre las expresiones regulares durante la etapa de capacitación. No es necesario pensar en las funciones comunes de la fórmula más adelante, porque no está disponible en la API. Está en la API 4. La importancia de la depuración. La función de depuración es muy útil e importante. A medida que aumenta el código, una vez que ocurre un error, no es suficiente preocuparse por ello y no es eficiente. La depuración es una herramienta eficaz para solucionar errores y debes aprender a utilizarla con frecuencia y acostumbrarte desde el principio.