Refactorización. Su manera de reducir la complejidad del código de clase grande con grandes métodos

Question

que tengo una clase de legado que es bastante complejo para mantener:

class OldClass { 
    method1(arg1, arg2) { 
     ... 200 lines of code ... 
    } 

    method2(arg1) { 
     ... 200 lines of code ... 
    } 

    ... 

    method20(arg1, arg2, arg3) { 
     ... 200 lines of code ... 
    }  
} 

Los métodos son enormes, no estructurado y repetitivo (desarrollador amado copiar/pegar aprroach) . Quiero dividir cada método en 3-5 pequeñas funciones, con un método Pulic y varios ayudantes.

¿Qué sugeriría? Varias ideas vienen a la mente:

• Añadir varios métodos de ayuda privados para cada método y unirse a ellos en #region (refactorización recta de avance)

• Uso de comandos patrón (una clase de comando por el método de OldClass un archivo separado).

• Crear clases estáticas auxiliares por método con un método público & varios métodos de ayuda privada. Los métodos OldClass delegan la implementación a la clase estática apropiada (muy similar a los comandos).

• ?

Gracias de antemano!

Answer 1

SRP - Principio de unión Responsabilidad y SECO - No te repitas

Answer 2

Comenzaría encontrando los bits que son repetitivos y extrayéndolos en funciones auxiliares. Una vez que haya reducido la base de códigos de esta manera, puede considerar otras formas de refactorización, y será mucho más fácil entender el código.

Answer 3

DRY - No se repita.

Lo primero que siempre hago es eliminar (todas) la repetición. Incluso una sola línea es repetición.

Eso normalizará el código y también le dará un montón de mejoras como la genérico del código.

Answer 4

Consulte SD CloneDR para obtener una herramienta que le puede decir qué bloques de código tienen cada uno de sus métodos en común, incluidas posibles parametrizaciones.

Answer 5

1. de inicio mediante la asignación de la funcionalidad actual y hacer un diagrama de clases UML. De esa forma puedes lograr DRY de manera efectiva.

2. Cambie el diseño para que sea efectivo y SECO, manteniendo la interfaz de su sistema lo más parecida posible.

3. Luego, escribe las pruebas unitarias para el sistema nuevo, sería mejor escribirlas también para el sistema anterior, pero como es probable que cambies los nombres y argumentos del método, las pruebas unitarias probablemente no funcionen en ambos sistemas.

4. Pregunte a su gerente los comentarios sobre la prueba de unidad, ¿entendió la funcionalidad correctamente?No implemente ninguna característica nueva, esto causará problemas con los sistemas existentes que usan el código, y si obtiene el nuevo diseño correctamente agregando nuevas características

5. Implemente el sistema aprobado.

6. Usar valores predeterminados como argumentos para reducir la sobrecarga: SelectUser(int userId = 0) se puede llamar con SelectUser();