Comunidad de diseño web y desarrollo en internet

Antipatrones God-Object en patrones de diseño orientado a objetos

Qué es un antipatrón?


En desarrollo de software un antipatrón es una mala práctica, que aunque puede solucionar un problema en nuestra aplicación, también puede generar problemas de mantenimiento, diseño o comportamiento en el software.

Se puede decir que un antipatrón es, como su nombre lo indica, lo opuesto a un patrón de diseño, sin embargo el saber identificar esos bad smells en nuestros proyectos se considera una buena práctica, ya que así podremos implementar una mejor solución y hacer más eficientes nuestras aplicaciones.

Con esta pequeña introducción quiero exponer uno de los antipatrones de programación más comunes: el God-Object.

God – Object


También conocido como The Blob, Winnebago o monster object



Con esos nombres ya deberían hacerse una idea de qué trata este antipatrón.

El Objeto todo poderoso es un objeto que hace mucho más de lo que debería osea no cumple con el principio de única responsabilidad, crece de manera descontrolada (como the blob) y se encarga de tantas cosas diferentes que todo el sistema termina dependiendo de él.

Por qué es malo?


  • Lo primero es que una clase tan grande seguramente será muy difícil de testear y de mantener debido a su complejidad.
  • Una clase con tantas responsabilidades no será reusable en ningún otro proyecto.
  • Clases muy grandes pueden cargar mucha información innecesaria en memoria degradando el rendimiento de nuestra aplicación.
  • Un god object no permite usar de buena manera los principios de orientación a objetos, por tanto no es fácil realizar cambios en la implementación de las clases sin afectar la funcionalidad de la aplicación.

Cómo sé si mi clase es un God-Object?


  • Cuando encuentren una clase con muchos atributos o muchas operaciones o ambas. Una clase con más de 60 atributos y operaciones habitualmente es un god object.
  • Atributos y operaciones diversas y sin conexión lógica entre ellas contenidas en una misma clase, una falta de cohesión de los atributos y operaciones es otro síntoma del God-Object.
  • Una ausencia de un diseño orientado a objetos, una única clase que se encarga de controlar y encapsular toda la funcionalidad de la aplicación es más un diseño procedimental que orientado a objetos.

Por qué tengo un god object en mi aplicación y qué necesito hacer para que no me ocurra de nuevo?


  • Falta de diseño orientado a objetos, los programadores requieren un poco mas de habilidad a la hora de abstraer y de entender un poco más los principios de orientación a objetos.
  • Falta de una arquitectura de software en el proyecto, que puede llevar a construir God Objects sin darse cuenta.
  • No existe una revisión a conciencia del código, para validar que se está manteniendo el principio de única responsabilidad para cada una de las clases que creamos o modificamos.

Refactorización


Si tenemos un god-object aún podremos realizar una refactorización de nuestra clase y de nuestro proyecto para asegurar que cada operación y cada atributo se encuentre en su respectiva clase.

  1. Lo primero es identificar agrupaciones de atributos y métodos que deberían estar encapsulados en una misma clase.
  2. Creamos estas clases y realizamos el respectivo ajuste en cada parte del código donde se usaba asignándolo a la nueva clase responsable.
  3. Debemos eliminar cualquier relación redudante que pueda quedar de la separación clases.
  4. Finalmente es cuestión de aplicar las buenas prácticas de software para ajustar el diseño.

Bibliografía:




Comentarios y sugerencias son bien recibidos. ^^

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.

Publica tu comentario

o puedes...

¿Estás registrado en Cristalab y quieres
publicar tu URL y avatar?

¿No estás registrado aún pero quieres hacerlo antes de publicar tu comentario?

Registrate