God Object

God Object

god object

El God Object un objeto muy grande, que conoce demasiado o tiene demasiadas responsabilidades distintas.

En este tipo de objetos , toda la funcionalidad del programa esta codificada él.

 

Usamos esta técnica ocasionalmente para entornos de programación ajustados, donde el aumento de rendimiento ligero y la centralización es más importante que el mantenimiento y la elegancia de programación.

 

Crear un God Object se le considera una mala práctica de programación. Es un ejemplo de un antipatrón de diseño.  Se le conoce también como el anti-pattern. Contradice y viola todas las reglas de diseño y código limpio.

El principal problema de este tipo de objecto es que nuestro código se volverá débil e inestable. Cualquier cambio en él, podrían suponer la aparición de errores o comportamientos inesperados. Además, se haría muy complejo su mantenimiento a largo plazo.

 

La solución para que podamos deshacernos de este tipo de objecto es  que refactorizar  el God Object en varios objectos lo más independientes posibles unos de otros.

Funciones, Código Limpio

 

NOMBRE

  • Deben ser verbos y los argumentos sustantivos
  • Deben ser pronunciables
  • Deben ser descriptivos
  • No preocuparse por la extensión del nombre, mas vale un nombre largo y descriptivo que uno corto y enigmatico.
  • No preocuparse en dedicarle tiempo a elegir un buen nombre.

ARGUMENTOS

  • Numero de argumentos ideal : 0
  • Máximo numero de argumentos: 3
  • Si hay gran cantidad de argumentos, desde el punto de vista de pruebas resulta muy complejo hacer todas las combinatorias posibles.
  • Argumento Indicador. No pasar booleano como parámetro a una función. Indicaría que hace mas de una cosa. Mejor dividir en dos funciones, una para cada caso.

TAMAÑO

  • Las funciones deben ser de tamaño reducido.
  • Mejor muchas funciones de tamaño reducido (3 o 4 lineas) que sean obvias.
  • Todas deben contar una historia y cada una debe llevar a la siguiente como contando una historia en orden atractivo.
  • No deben tener estructuras anidadas en su interior.

SWITCH

El buen uso de la instrucción switch se puede admitir si:

  • Aparecen una vez
  • se utilizan para crear objectos polimorficos
  • Se ocultan tras una relación de herencia para que el resto del sistema no las pueda ver.

ALCANCE

  • Las funciones solo deben hacer una cosa. Deben hacerlo bien y debe ser lo único que hagan. Sin efectos secundarios.
  • Solo debe o hacer algo o responder algo, pero no ambas cosas. O cambia el estado de un objeto o devuelve informacion sobre el mismo.
  • Una forma de saber que una función hace mas de una cosa es extraer otra función de ella, con un nombre que no sea una reducción de su implementación.
  • Debe mantener el nivel de abstracción dentro de la misma función.
  • Una función que procese errores no debe hacer nada mas. Si una función incluye try and catch no debe haber mas código después de ahí.

DUPLICACIÓN DE CÓDIGO

La duplicacion implica:

  • El doble de riesgo a errores
  • El doble de mantenimiento.
  • Con cualquier cambio habra que cambiarlo X numero de veces
  • Se empeora la legibilidad del codigo.

SOLO UNA ENTRADA Y UNA SALIDA

Las funciones solo deben tener una funcion return.

REGLA DESCENDENTE

El código debe leerse como un libro, de arriba a abajo. Ir de las funciones menos abstractas a las mas abstractas mientras bajamos en el código.

 

CREACIÓN DE FUNCIONES LIMPIAS

  • Primero se escribe el primer borrador. Este puede estar desorganizado, con funciones extensas y complicadas, con bucles anidados ….
  • Se hace va haciendo refactor del código poco a poco, mejorandolo. Se retoca el código, se divide las funciones, se cambian nombres, se elimina los duplicados, se reordena,….
  • Al final se consiguen funciones limpias. No se escriben al comenzar a programar. Es un proceso el cual hay que seguir.