2010-02-08 20 views
21

When is a function too long? es un subconjunto de esta pregunta, creo.¿Cuándo es una clase demasiado larga?

¿Cuáles son algunas buenas métricas para determinar que una clase es demasiado larga?

Estoy revisando un conjunto de pautas de aceptación de código para un proyecto con contratistas externos, y me di cuenta de que no he cubierto esto en el pasado, pero debería cubrir esto en el futuro.

+0

¿qué idioma?Creo que la respuesta difiere, por ejemplo, para Java versus Scala. En este último caso, las clases son típicamente (¡y deberían ser!) Más cortas. –

+0

Eche un vistazo a esta pregunta - http://stackoverflow.com/questions/849557/in-c-how-many-lines-before-a-class-should-be-consider-to-be-refactored/ –

+0

De cerca pregunta relacionada: http://stackoverflow.com/questions/1086851/good-practice-class-line-count/1086865#1086865 – sleske

Respuesta

61

Cuando tiene más de una responsabilidad.

Permítanme citar de Robert C. Martin Clean Code aquí:

La primera regla de clases es que deben ser pequeñas. La segunda regla de clases es que deberían ser más pequeñas que eso. ... Con las funciones medimos el tamaño contando las líneas físicas. Con clases, utiliza una medida diferente. Contamos responsabilidades. [Capítulo 10, página 136]

+3

+1 respuesta superior señor. – Matt

+0

Esto obviamente no es cierto. ¿Alguna vez usó tarjetas CRC (clase, responsabilidad, colaborador), una de las herramientas clásicas utilizadas en el diseño OO? Cada tarjeta tiene una sola clase y una lista de VARIAS responsabilidades en ella. –

+0

@Neil, yo diría que los métodos de diseño OO de los años 80 no incorporan el gran cuerpo de experiencia que se ha obtenido desde entonces. Todavía el concepto de estas cartas parece ser útil, ¡así que gracias por mencionarlas! – Thorsten79

2

Una clase debe tener una sola responsabilidad. Esa es una medida mejor que su longitud. Entonces, cuando diseñe su código, cada unidad de su diseño (un tipo o una clase) debería ser responsable de una sola cosa (cualquiera que sea "una cosa" es en su caso). Si lo mantienes lo más simple posible, no te meterás en un lío.

1

Cuando piensas que ahora te ha resultado más difícil manejarlo y te atasca.

+0

Estoy tratando de encontrar un estándar para que otros lo sigan; Tengo unas 3000 clases de línea, y aunque quiero explicarles que es una mala idea, estoy tratando de establecer reglas para evitar que tenga que actuar como un respaldo en el futuro. –

1

Ignorando el patrón de diseño en uso, consideraría el alcance de la responsabilidad que cumple la clase. Si el alcance es demasiado grande, debe dividirse en responsabilidades específicas, abstraerse o hacerse más genérico.

Realmente no tomaría el número de líneas como una métrica significativa.

+0

Nada preocupado por las "líneas de código" como la métrica, simplemente tratando de encontrar métricas más significativas para tomar su lugar. –

10

No más de 17 líneas. Ni mas ni menos. Entonces, si está por debajo de las 17 líneas, los retornos de carro harán el truco. Si es más de 17, deberá comenzar a llamar a otras funciones desde dentro de la función.

Por ejemplo:

public function myFunction() { 
... 
line 17: myFunctionPart2(); 
} 

public function myFunctionPart2() { 
... 
line 17: myFunctionPart3(); 
} 

Y así sucesivamente.

Su práctica de programación bastante estándar.

+1

Preguntaba por clases ... no por funciones. 17 líneas en una clase serían menos que pequeñas. –

+5

Oh, para las clases, el límite es de 19 líneas. – wowcat

+6

+1 porque esto es gracioso. – Steven

15

Complejidad de despliegue de clase: El número de otras clases en las que se basa una clase determinada. También se ha demostrado que el cuadrado de esto indica la cantidad de mantenimiento requerido en los programas funcionales (en base a archivos) al menos.

Complejidad ciclomotriz: Comprueba la complejidad ciclomática contra un límite especificado. La complejidad se mide por el número de if, while, do, for,?:, Catch, switch, case statements y operadores & & y || (más uno) en el cuerpo de un constructor, método, inicializador estático o inicializador de instancia. Es una medida del número mínimo de rutas posibles a través de la fuente y, por lo tanto, del número de pruebas requeridas. ¡Generalmente 1-4 se considera bueno, 5-7 está bien, 8-10 considera volver a factorizar, y 11+ vuelve a factor ahora!

+0

Volviendo a esto años después; la complejidad ciclomática es una buena aproximación de primer orden, pero solo está probando cada método individual, y suele ser una pista falsa; es medir la dificultad del código, pero lo que realmente querría saber es cuánta dificultad * tenía * para estar ahí. (Escribir código complejo está bien si el motivo es complejo; escribir código de complejidad media es malo si hubiera sido trivial). –

Cuestiones relacionadas