Refactorización en muchos métodos: ¿se considera esto correcto o no? [duplicar]

El LoC en un método es una medida completamente inútil. Las cosas importantes son la separación de preocupaciones y la duplicación de código.

Un método solo debe hacer una cosa, y esa cosa debe expresarse en su nombre. Otras cosas deben dejarse a otros métodos.

Los problemas que surgen de la duplicación de código no se pueden sobreestimar (en otras palabras, siempre son más grandes de lo que crees). Y eso solo justificará incluso los métodos con 1 línea de código.

Por otro lado, un método que llena una forma grande con detalles de un objeto de datos grandes puede tener fácilmente 50 o más líneas de código, pero sin una sola declaración condicional. ¿Por qué querría dividirlo en partes más pequeñas si no hay requisitos funcionales (o duplicación de código)?

Los métodos más cortos son mucho más legibles: menos cosas para tener en cuenta para entenderlas . Los defensores más vocales del código limpio probablemente dirían que casi todos los métodos deben ser más cortos que 8 líneas. Y casi todos los desarrolladores que estén interesados en el tema estarán de acuerdo en que entre 70 y 80 líneas de código en un método es demasiado y debería dividirse.

Se trata de la separación de las preocupaciones. El método debe responder a 1 pregunta o tomar 1 decisión. Y eso es todo. Por lo tanto, tener los métodos de 100 líneas de código significa que estos métodos son simplemente demasiado. 7-8 Los métodos de LoC son absolutamente excelentes. La otra pregunta es: ¿dónde vas a poner todos estos métodos? Tener 20 métodos cortos en una sola clase es probablemente un tema de preocupación. Tener 30 de ellos es, creo, la buena razón para entender que algo anda mal con las abstracciones. Solo mantén todo lo más breve y simple posible.

Hay una escuela de pensamiento que dice que 7-8 LOC es un poco largo para un método. No estoy suscrito a eso, pero diría que siga adelante: cualquier cosa que no sea una pantalla es buena para mí.

Los métodos deben ser tan simples como necesarios , pero no más simples.

LoC simplemente no es una métrica valiosa. En su lugar, mira cuánto hace un método. Un método generalmente debería hacer una cosa. En mi humilde opinión, a veces es bueno abordar 1 o 2 operaciones muy simples. Por ejemplo, calculando el perímetro de un rectángulo:

Podría ser:

public int GetPerimeter(int side1, int side2)
{
    totalWidthLength = side1 * 2;
    totalHeightLength = side2 * 2;
    return totalWidthLength + totalHeightLength;
}

-OR-

public int GetPerimeter(int side1, int side2)
{
    return DoubleSide(side1) + DoubleSide(side2);
}

private int DoubleSide(int side)
{
    return side * 2;
}

Personalmente, prefiero el primer método, aunque técnicamente realiza más de una operación. Al mismo tiempo, también puede tener métodos con muchas líneas de código que son fáciles de leer y entender.

public void UpdateCustomer()
{
    customer Customer = new Customer();

    customer.Name = textboxName.Text;
    customer.AddrLine1= textboxName.Text;
    customer.AddrLine2 = textboxName.Text;
    customer.OfficialName = textboxName.Text;
    customer.Age = textboxName.Text;
    customer.BirthDay = textboxName.Text;
    customer.NickName = textboxName.Text;
    customer.LastLocation = textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;

    db.InsertOnCommit(customer)
    db.SubmitChanges();
}

El ejemplo anterior es de aproximadamente 50 líneas, pero incluso podría ser de 200 líneas, y no haría ninguna diferencia. Cada asignación de propiedad en el objeto del cliente no agrega prácticamente ninguna complejidad, por lo que el método de 50 líneas permanece en el mismo nivel de complejidad que su método promedio de 4 líneas. De hecho, me atrevería a decir que tiene básicamente la misma legibilidad que el método a continuación:

public void UpdateCustomer()
{
    customer Customer = new Customer();

    customer.Name = textboxName.Text;

    db.InsertOnCommit(customer)
    db.SubmitChanges();
}

El método de 50 líneas probablemente podría lograrse en menos de 10 líneas mediante el uso de reflejo y expresión regular, repitiendo cada una de las propiedades en el Cliente y buscando un cuadro de texto que tenga un valor LIKE coincidente en su nombre. Obviamente, ese sería un ejemplo de código que es demasiado inteligente y recurre a hackes extravagantes para lograr un ideal estético. La conclusión es que la LoC es una métrica de complejidad / legibilidad extremadamente poco confiable. Todos ya saben esto (mi ejemplo de CRUD no es en absoluto infrecuente), y sin embargo, mientras la mayoría de las personas hablan de lo horrible que es la LoC para medir productividad, escuchamos constantemente sobre este LoC por reglas de método que se supone que miden la calidad del código. Realmente no puede ser en ambos sentidos.