section name div definir attribute class refactoring anti-patterns god-object

class - name - ¿Cómo refactorizas una clase de Dios?



h2 class css (2)

Asumo que "Objeto de Dios" significa una clase enorme (medida en líneas de código).

La idea básica es extraer partes de sus funciones en otras clases.

Para encontrar los que puedes buscar.

  • Campos / parámetros que a menudo se utilizan juntos. Podrían mudarse juntos a una nueva clase.

  • Los métodos (o partes de métodos) que usan solo un pequeño subconjunto de los campos de la clase, podrían pasar a una clase que contenga solo esos campos.

  • Tipos primitivos (int, String, boolean). A menudo realmente valoran los objetos antes de que salgan. Una vez que son objeto de valor, a menudo atraen métodos.

  • mira el uso del objeto dios. ¿Existen diferentes métodos utilizados por diferentes clientes? Esos podrían ir en interfaces separadas. Esas interfaces podrían a su vez tener implementaciones separadas.

Para realizar estos cambios, debe tener alguna infraestructura y herramientas a su disposición:

  • Pruebas: Tenga listo un conjunto exhaustivo (posiblemente generado) de pruebas que puede ejecutar con frecuencia. Ten mucho cuidado con los cambios que haces sin pruebas. Los hago, pero los limito a cosas como el método de extracción, que puedo hacer completamente con una sola acción IDE.

  • Control de versión: desea tener un control de versión que le permita realizar cada 2 minutos, sin ralentizarlo. SVN realmente no funciona. Git lo hace.

  • Método Mikado: la idea del método Mikado es intentar un cambio. Si funciona bien. Si no toma nota de lo que se está rompiendo, agréguelos como dependencia al cambio con el que comenzó. Rollback te cambia. En el gráfico resultante, repita el proceso con un nodo que aún no tiene dependencias. http://mikadomethod.wordpress.com/book/

¿Alguien sabe la mejor manera de refactorizar un objeto de Dios?

No es tan simple como dividirlo en varias clases más pequeñas, porque hay un método de acoplamiento alto. Si saco un método, por lo general termino sacando todos los otros métodos.


Es como Jenga. Necesitará paciencia y una mano firme, de lo contrario tendrá que recrear todo desde cero. Lo que no está mal, per se, a veces hay que tirar el código.

Otro consejo:

  • Piensa antes de sacar métodos: ¿en qué datos opera este método? ¿Qué responsabilidad tiene?
  • Intente mantener la interfaz de la clase de dios al principio y delegue las llamadas a las nuevas clases extraídas. Al final, la clase de dios debería ser una fachada pura sin lógica propia. Luego puede guardarlo por conveniencia o desecharlo y comenzar a usar las nuevas clases solamente
  • Ayuda de Pruebas unitarias: escriba pruebas para cada método antes de extraerlo para asegurarse de que no rompe la funcionalidad