2009-05-11 14 views
16

Una buena regla general es que refactorizo ​​inteligentemente cualquier método de más de 50 líneas.En C# ¿Cuántas líneas antes de una clase se deben considerar para ser refactorizadas?

El recuento no incluye comentarios y espacios en blanco, pero el código real. La razón por la que también digo inteligentemente es que hay muchas veces en las que una clase de más de 50 líneas es aceptable y no puede o no debe cambiarse.

No tengo una regla general para las clases. En general, no reviso las clases para ver si deberían ser refactorizadas.

En mi proyecto actual, casi he completado una clase de casi 4000 líneas. Sin embargo, no hay métodos de más de 50, y la mayoría de las líneas y métodos son privados y no actúan sobre ningún dato fuera de la clase.

¿Cuál es la regla de oro para refactorizar clases?

+4

Por favor, nos muestran un método de 50 líneas que no se pueden reducir. –

+1

Preferiría uno, sin embargo, el método de 50 líneas no es relevante para esta discusión, así que no lo agregaré. Esa sería una publicación de blog. –

+0

Longhorn213: Creo que deberías considerar la posibilidad de aplicar un método de 50 líneas que no se puede reducir. El análisis de lo que se puede hacer puede darle una gran idea de cómo se puede refactorizar la clase en sí misma. Todavía tengo que cumplir con un método de 50 líneas que no se puede romper de una manera significativa. –

Respuesta

40

Cuando la clase infringe el SRP, es hora de refactorizar.

+0

Me encanta SRP. Buen comentario. –

+0

Nice answer. ;) – DaDa

+0

Longhorn213: Eso es correcto. Si realmente no viola a SRP, dividirlo en una clase separada es contraproducente. Sin embargo, puede refactorizar la clase en sí misma en métodos más pequeños. –

1

La refabricación no se trata tanto de reducir el número de LOC, aunque es un efecto secundario, sino que mejora la calidad. En particular, desea tratar de seguir el principio DRY (No repetir) en la medida de lo posible, de manera razonable.

5

No diría que hay una "regla de oro" para refactorizar clases grandes. A veces, una clase realmente encapsula mucha lógica comercial y debería ser tan grande como lo es. Sin embargo, es posible considerar hacerse algunas preguntas:

  1. (Suponiendo que estás escribiendo código orientado a objetos) es verdaderamente orientada a objetos mi código? Es decir, ¿sigue el Principio de Responsabilidad Individual (gracias, Nebakanezer)? ¿Es esta clase una clase de ayuda? De ser así, ¿cómo podría refactorizar sus métodos en clases de objetos más apropiadas?

  2. ¿Tengo una arquitectura sólida? Es decir, ¿estoy haciendo uso de la abstracción y la herencia en lugar de reinventar la rueda en cada clase? ¿Los métodos sobrecargados están llamando a los métodos base según corresponda?

  3. ¿Realmente necesito todo este código? ¿Se podría externalizar parte de la lógica usando xpath, expresiones lambda o alguna forma de expresiones impulsadas por bases de datos?

  4. ¿El código es extensible? ¿Es fácil de mantener? ¿Estaba bien estructurado desde el principio o siempre estamos haciendo pequeños parches para tratar de solucionar los problemas?

Espero que esto ayude un poco; puede ser difícil refactorizar grandes clases, pero creo que si empiezas a analizar mis preguntas, es muy probable que encuentres mejoras en tu código ... Sé que normalmente lo hago.

Mire especialmente el n. ° 1: es muy común que las personas creen una tonelada de clases de ayuda por todas partes, lo que es muy contrario a los objetos (en mi opinión). Ese es un tema diferente, pero es posible que desee ver lo que realmente "pertenece" en la clase que ha creado y lo que podría/debería ser en otro lugar.

Como regla general, si la clase es fácil de mantener y flexible, es posible que no sea necesario cambiarla. :)

+0

Yo agregaría, 5. ¿Mi clase es fácilmente comprobable por unidad? Las clases hinchadas grandes a menudo son difíciles de evaluar en una unidad, lo que puede ser una señal de que está haciendo demasiado. – user441521

4

En C#, mi regla de oro para las clases es algo más de 500 líneas es demasiado larga. Me gustan mucho los métodos de menos de 10 líneas, y creo que menos de 20 es aceptable.Creo que realmente depende del contexto.

1

Mi regla de oro es para los métodos, más que para las clases: si no puedo ver todo el método en la pantalla, debe ser refactorizado. Por supuesto, se aplica el traditional smells.

2

Refactor cada vez que tenga la oportunidad de:

  • introducir los patrones de diseño apropiados en lugar del código espagueti
  • reducir la complejidad de código y aumentar la legibilidad
  • eliminar código redundante mediante la introducción de un único método llamado
  • extricate interfaz de usuario de la lógica de negocio

etc, etc

EDIT: Obviamente, la decisión de refactorizar debe tener en cuenta el tiempo, el potencial de rentabilidad, otras responsabilidades, etc.

8

No deje LOC sea su principal métrica. 50 líneas me parecen realmente pequeñas. Con 50 archivos de línea, terminará teniendo una cantidad desagradable de archivos de clase en la solución. Su productividad se verá atenuada por toda la navegación que realizará entre los archivos y su IDE siempre estará lleno de demasiadas pestañas. Personalmente trato de organizar las clases en grupos lógicos por espacio de nombres primero. En una clase por clase, trato de hacer que el código sea más pequeño y más fácil de leer. A veces, los archivos de clase se vuelven grandes. Empiezo a sentirme mal cuando el archivo de la clase tiene más de 2000 líneas. Cualquier cosa menos que eso, me ocupo caso por caso.

+0

Me encanta tu elección de palabras: una sensación de malestar. Jaja. Tengo la misma sensación cada vez que veo a las personas implementar su propio algoritmo de clasificación solo para ordenar una matriz de números. :) –

+1

LOC no es el punto principal (+1) pero con un IDE bueno, nunca se debe forzar a saber dónde está realmente el código. Raramente debería navegar por nombre de archivo/número de línea o incluso "por encima de blaa en el archivo" – BCS

+0

para Visual Studio, Resharper FTW. Navegar es muy sencillo con Resharper (CTRL + SHIFT + T). –

1

Tiendo a mirar la complejidad ciclomática de cada miembro en lugar de la cantidad de líneas de código para toda la clase.

0

Esta clase podría ser un candidato para el ejercicio de refactorización de "extraer un objeto que no pienses que está allí"?

Quizás, por ejemplo, podría extraer un objeto de método que le permita refactorizar varios de los 50 métodos de línea en miembros de una clase extraída.

De forma alternativa, encapsular algunos de los métodos privados que contienen lógica comercial en un nuevo objeto que colabora con este podría proporcionar una nueva forma de reutilizar este objeto o el que se extrajo.

Una línea es suficiente para considerar la refactorización. 40 cada 50 métodos de línea está empezando a gritar "Soy demasiado complicado, hay otro objeto escondido aquí" en mi oído.

16

Si han roto uno de los siguientes ... es hora de refactorizar. Hey, tipo al que están buscando SÓLIDO ... screencasts are here

  • S RP: Responsabilidad Individual principio, no debe nunca más de una razón para una clase CAMBIAR

  • O CP: Principio abierto abierto, ENTIDADES DE SOFTWARE (CLASES, MÓDULOS, FUNCIONES, ETC.) Debe estar abierto a extensión, pero CERRADO DE MODIFICACIÓN

  • L SP: principio de sustitución de liskov, las funciones que utilizan ... referencias a clases base debe PODRÁ UTILIZAR OBJETOS DE clases derivadas sin saberlo.

  • I SP: Interfaz Segregación principio, los clientes no deben ser forzados a depender de interfaces que no utilizan

  • D IP: Dependencia Inversión Principio,

    A. ALTO NIVEL LOS MÓDULOS NO DEBEN DEPENDER DE LOS MÓDULOS DE BAJO NIVEL. AMBOS DEBERÍAN DEPENDER DE LAS ABSTRACCIONES

    B. LAS ABSTRACCIONES NO DEBEN DEPENDER DE LOS DETALLES. DETALLES debe depender de ABSTRACCIONES

Y todo, divertirse :)

+1

Yo iba a sugerir SÓLIDO como línea base, pero me ganaste. ;) – Tracker1

+11

Su bloqueo de mayúsculas está todavía activado. –

Cuestiones relacionadas