Refactorización de un método grande en .NET

Question

Si tengo un método .NET grande, quiero saber si es una buena práctica dividirlo en varios métodos o no. Mis preocupaciones son: 1 - ¿Hay algún punto para crear un método si solo se llama una vez?
2 - Si invoco un método privado desde mi clase, trato de no utilizar variables de instancia. ¿Es esta buena o mala práctica? Por ejemplo:

var a, b; 
public void TestMe 
{ 
    FirstTest(a,b); 
} 
private void FirstTest(paramA, paramB) 
{ 
     //code here with passed in parameters 
} 

//instead of: 
private void FirstTest() 
{ 
     //code here with instance variables a,b 
} 

edición: sustituir global con instancia

Answer 1

1 - ¿Hay algún punto para crear un método si solo se llama una vez?

Sí, hay muchas razones para hacer esto. La legibilidad es quizás la más importante. Si puede hacer que un método sea más legible y mantenible dividiéndolo, entonces hágalo de todos modos.

En mi experiencia con la refacturación de código heredado donde un método es demasiado largo, hay pequeños fragmentos de código que aparecen una y otra vez.Estos suelen ser los mejores lugares para buscar oportunidades de refactorización. La creación de métodos separados para esas piezas puede disminuir en gran medida la longitud de un método y, por lo tanto, aumentar su legibilidad.

2 - Si yo estoy llamando a un método privado desde el interior de mi clase, trato de no usar variables de instancia. ¿Es esto bueno o mala práctica?

Normalmente, cuanto más pequeño sea el alcance de una variable, mejor. Como tú, tiendo a usar parámetros siempre que sea posible. Si un método tiene referencias solo a sus propios parámetros, entonces es mucho más fácil razonar sobre el método, verificar su corrección y usarlo correctamente. (Y si un método puede hacer esto y no modificar su estado, luego de que se compra una gran cantidadde las prestaciones de mantenimiento.)

Si el propósito de un método es mejor servido por la manipulación de los campos de un objeto, entonces eso es perfectamente aceptable, y en muchos casos, inaceptable. Pero, como usted indica, esto es especialmente cierto con los métodos públicos. Al refacturar un método grande en otros más pequeños, raramente, o nunca, accederá a los campos de miembros directamente en los nuevos métodos. Esto es principalmente para simplificar el razonamiento sobre el comportamiento del programa.

Al refaccionar de esta manera, asegúrese de marcar los nuevos métodos como static si no tienen acceso a ningún campo. Esto hará que el intento sea explícito.

Answer 2

1. Si una pieza de código es sólo va a ser llamado una vez, no es muy probable que no es una razón para crear el método en el primer lugar. SIN EMBARGO, dicho esto, si se trata de un método privado y se utiliza como una función separada (una preocupación aparte), entonces podría ser una buena idea dividirlo. Debería hacer esto para evitar tener un solo método enorme. Un ejemplo sería, si solo hago una búsqueda una vez en un fragmento de código, aún así querré dividir esa búsqueda porque la búsqueda es una función separada. (Este es un ejemplo muy pobre. Si alguien tiene uno mejor, siéntase libre de editarlo.

2. Una variable no es REALMENTE global a menos que sea accesible en todo el sistema. Dicho esto, lo recomendaría encarecidamente evitando variables globales porque hace que sea muy difícil depurar y trabajar con código porque las variables tienen un alcance extremadamente grande. En cambio, me centraría en tener variables más localizadas y pasar las variables que una función/método puede necesitar y devolver datos que la función del que llama espera. De esta forma, mantendrá sus datos más localizados y, en última instancia, el código será más fácil de leer y administrar. Hacer esto no es particular para los métodos privados o públicos

Answer 3

Con respecto a su primera pregunta, reducir la complejidad en un método es motivo suficiente para dividir un método grande en uno pequeño. Los métodos más pequeños son mucho más fáciles de comprender que un solo método grande. Si se hace correctamente, dividiendo el método en unidades de trabajo lógicamente consistentes, en casi todos los casos se prefieren muchos métodos pequeños a un solo método grande. Las únicas condiciones en las que podría no serlo es si impacta su rendimiento hasta el punto en que ya no es aceptable desde esa perspectiva.

Con respecto a la segunda pregunta, como señala @Jason, está utilizando variables de instancia no globales dentro de su clase. Diría qué práctica se prefiere depende del contexto del método. Ciertamente, si el método puede reutilizarse en muchos contextos, solo algunos de los cuales operan en variables de instancia, debe ser parametrizado. Si solo está utilizando las variables de instancia, puede optar por no tener los parámetros, y refactorizar según sea necesario más adelante para la usabilidad.

En C#, yo también preferiría usar instancia propiedades más campos, desvincular aún más la propiedad del método de usarlo.

Answer 4

Para citar de Clean Code (un excelente libro), un método debe hacer una cosa y una sola cosa. Si está haciendo varias cosas en un método, probablemente signifique que necesita extraer esa lógica en un método diferente. También hace que sea mucho más fácil seguir el código. Así que yo diría

Pregunta 1: Sí, sepárela (separación de la preocupación).

Pregunta 2: En general, creo que es una mala práctica tener variables globales a menos que sea absolutamente necesario para. En cuanto a la cuestión general de usar la propiedad privada (variable de instancia) por sí misma sobre el captador público, no veo ninguna ventaja al utilizar el captador. Por ejemplo, considere:

function someFunc() { 
    anotherFunc(this.a, this.b); 
} 

function anotherFunc(int paramA, int paramB) { 
    //do stuff with paramA and paramB 
} 

frente

function someFunc() { 
    anotherFunc(); 
} 

function anotherFunc() { 
    //do stuff with this.a and this.b 
} 

En algún momento había tienen para referirse a la variable de instancia mediante el uso de this. Entonces no veo una ventaja. Después de todo, usted es dentro de su clase, por lo que tiene acceso completo a miembros privados.