java - los - metodos de clase awt

¿Cuántas clases por paquete? métodos por clase? líneas por método? (6)

(nota: tl; dr disponible en la parte inferior para mi opinión real)

No citaré ningún nombre importante y diré que esa es la respuesta correcta porque siempre depende de cada caso cómo haces todo esto. Por ejemplo, la cantidad de métodos: si está creando un software de control para el control remoto del televisor HD LCD moderno que tiene unos 40-50 botones, ¿cómo puede dividirlo en clases coherentemente para que solo tenga, digamos, 7 métodos? ¿por clase?

Personalmente, me gusta mantener todos los métodos de un nivel de acceso en una clase, lo que significa que algunas clases de utilidad pueden tener cientos de métodos, pero en mi opinión es más fácil hacer algo como StringUtil.escapeXMLspecialCharacters(someString) que StringUtil.XML.escapeSpecialCharacters(someString) o XMLUtil.escapeSpecialCharacters(someString) . Si bien todas estas son soluciones aparentemente correctas, la primera prospera (al menos en mi mente, eso es!) Porque es una manera simple y muy fácil de acceder a ese método: no tienes que pensar si la cadena que estás manejando contiene XML o XHTML o JSON o lo que sea, simplemente elegirás un método del grupo general de métodos y eso es todo.

Manteniendo la analogía remota de TV anterior, supongamos que los divide en varias clases de todos modos. Si nos permitimos tener 7 de esos métodos por clase en promedio y logramos agrupar los botones del control remoto en grupos MenuButtons como MenuButtons , AdjustmentButtons y ''NumberSelectorButtons'', terminamos con 8 o más clases. Eso no es malo en realidad, pero se vuelve un poco confuso, especialmente si no están divididos en grupos sensoriales con gran cuidado. Solo imagina los desvaríos alrededor de la oficina de TVRemotes''R''Us Inc.: "¿Quién dice que el botón de encendido / apagado es un botón de control?" "¿Quién es el comodín que pone el volumen +/- en los botones de menú? PRE / CH (el botón que cambia entre el canal actual y el canal anterior y / o fuente de imagen) ¡ no es un botón numérico!" "El botón de guía abre la guía de televisión Y el menú de navegación según el contexto, ¿¡qué vamos a hacer con él !?"

Entonces, como puedes ver en este ejemplo, usar un número arbitrario para limitarte a ti mismo podría introducir cierta complejidad innecesaria y romper el flujo lógico de la aplicación.

Antes de arrojar mis últimos dos centavos, una cosa sobre el número de líneas por método: Piense en el código como bloques. Cada bucle es un bloque, cada condicional es un bloque y así sucesivamente. ¿Cuál es la cantidad mínima de estos bloques necesarios para una unidad de código que tiene una sola responsabilidad? Ese debería ser su limitador, no el deseo de tener "Siete en todas partes". a partir del número de clases en paquete, métodos en clases y líneas de código en métodos.

Y aquí está el TL; DR :

Por lo tanto, mi opinión real es esta: el número de clases en el paquete debe ser bastante bajo. Últimamente he empezado a hacer lo siguiente, pero no estoy seguro de si voy a estar a la altura:

El paquete foo contiene interfaces y otras clases comunes para implementaciones.
El paquete foo.bar contiene la implementación de dichas interfaces para la bar funciones
El paquete foo.baz contiene la implementación de dichas interfaces para la función baz

Esto generalmente significa que toda mi estructura tiene un número de clases coherente (y probablemente bajo) y al leer las interfaces de clase de nivel superior (y sus comentarios) también debería ser capaz de entender los otros paquetes.

Métodos por clase: todos los que se necesitan como he explicado anteriormente. Si su clase no puede vivir sin 170 métodos, déjelos. Refactorizar es una virtud, no algo que se puede aplicar todo el tiempo.

Líneas por método: lo más bajo posible, generalmente termino con 10 a 25 líneas por método y 25 es un poco alto para mí, así que diría que 10 es un buen punto de equilibrio para eso.

Tengo que dar una nota general a un gran proyecto de Java para el que tengo poca visibilidad y me preguntaba si había alguna guía para determinar:

qué número de clases por paquete se puede considerar correcto, bajo o alto (este proyecto tiene 3,89 clases por paquete, lo que me parece demasiado pequeño),
cantidad de métodos por clase? (este proyecto tiene 6.54 métodos por clase ...
número de líneas por método? (Este proyecto tiene alrededor de 7 líneas por método (me parece bastante bueno, tal vez un poco bajo))

Debo señalar que esta pregunta solo trata de volumetría. Tengo un montón de informes de herramientas de calidad (checkstyle, jdepend, cpd, pmd, ncss) que me dan más visión sobre la redundancia del código, el uso de clases, errores, etc.

Creo que las estadísticas de este tipo son bastante inútiles, ¿cómo saber las líneas por método muestra si es útil o no para el proyecto? Creo que deberías buscar más en la línea de:

¿Sus paquetes abarcan como clases?
¿Sus clases funcionan como una entidad por su cuenta?
¿Los métodos dentro de las clases funcionan de manera correcta y eficiente?

Seguramente, aparte del uso de memoria, no importa si el método es grande o no. la otra cosa que hay que buscar en métodos muy prolongados es si el seguimiento de la pila va a ser más grande que si se añadiera esa funcionalidad a un método principal. Sería cauteloso de medir el éxito de un proyecto basado en las líneas de código.

Una guía de diseño útil dice que cada clase solo debe hacer una cosa y hacerlo bien. Esto no le dará un número fijo de métodos por clase, pero limitará el número y hará que la clase sea más fácil de comprender y mantener.

Para los métodos, puede adoptar una vista similar y apuntar a métodos que sean lo más pequeños posible, pero no más pequeños. Piénselo de esta manera: si puede dividir el método en dos o más partes distintas, obviamente no es tan pequeño como podría ser. Los métodos pequeños son fáciles de entender y, al dividir el código de esta manera, obtendrá una mejor visión general en métodos de alto nivel y detalles de inserción a métodos de bajo nivel.

Desafortunadamente, no existe una noción absoluta (objetiva) de calidad en el software. Por lo tanto, no hay un valor "correcto" para estos. Sin embargo, aquí hay dos obsevaciones (personales):

3.89 clases / paquete es muy bajo. Significa que estarás luchando a través de un complicado árbol de paquetes.

7 líneas por método: de hecho suena bien. Sin embargo, si se llegó a este número como resultado de un esfuerzo intencional para reducir el recuento de líneas de los métodos, es posible que haya terminado con una única tarea lógica distribuida en varios métodos privados que dificultará la comprensión de la clase ( en algunos casos). De hecho, en CodeComplete-2, el autor cita una investigación que descubrió que la longitud del método es mucho menos importante que su complejidad ciclomática y su nivel de anidación.

Robert C. Martin, quien recientemente lanzó el libro "Código limpio", afirma que el número de líneas por método debe ser el más pequeño posible. Entre 1 y 7 líneas es una buena regla empírica.

También se hace un buen comentario en el libro The ThoughtWorks Anthology, en el ensayo "Object Calisthenics" de Jeff Bay. Él sugiere 9 limitaciones bastante graves que te harán un mejor desarrollador de OO a largo plazo. Lee más sobre ellos aquí.

Para responder a sus preguntas específicas, estas son las limitaciones específicas para usted: - No más de 10 clases por paquete - Un máximo de 50 líneas por clase

Estas restricciones pueden no ser ideales para todos sus proyectos reales, pero usarlos en un proyecto pequeño (hobby?) Lo forzará a una mejor práctica.

Steve McConnell en su libro Code Complete recomienda aproximadamente 7 métodos por clase y no hay más líneas en un método que luego se puedan ver en una sola pantalla sin desplazarse.

No estoy seguro de las clases por paquete.

Recomiendo leer Code Complete para obtener más información sobre estos temas.