Materia: Programación Orientada a Objetos
Hora: Jueves m1 - m3
*Anti patrones
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 esosbad 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.
Algunos ejemplos de anti patrones son:
*God - Objetc: es también conocido como The Blob, Winnebago o monster object. 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.
Este tipo de anti patrón es malo porque:
- 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.
*God - Objetc: es también conocido como The Blob, Winnebago o monster object. 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.
Este tipo de anti patrón es malo porque:
- 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.
Para saber si tienes clases con God- Objetc tienes que checar los siguientes puntos:
- 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ñoprocedimental que orientado a objetos.
* Lava Flow o Dead Code aparece principalmente en aquellos sistemas que comenzaron como investigación o pruebas de concepto y luego llegaron a producción. La principal característica de este anti patrón es la presencia de distintos flujos o corrientes de previos desarrollos que quedaron diseminados, y se hicieron inservibles. Estos desarrollos anteriores (a modo de investigación) a menudo probaban distintos enfoques para resolver distintos problemas, usualmente apresurados para entregar a término para una demostración, omitiendo documentación.
* Poltergeists, o Gipsy, o Proliferation of Classes, o Big DoIt Controller Class. Las clases poltergeists (fantasmas) se caracterizan por tener pocas responsabilidades dentro del sistema y un ciclo de vida bastante breve, ya que “aparecen” solamente para iniciar algún método en alguna clase, a menudo en un determinado orden. Son de relativa facilidad de encuentro ya que sus nombres suelen llevar el sufijo “controller” o “manager”. Estas clases desordenan el diseño ya que agregan abstracciones innecesarias, son excesivamente complejas, difíciles de mantener y comprender.
- 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ñoprocedimental que orientado a objetos.
* Lava Flow o Dead Code aparece principalmente en aquellos sistemas que comenzaron como investigación o pruebas de concepto y luego llegaron a producción. La principal característica de este anti patrón es la presencia de distintos flujos o corrientes de previos desarrollos que quedaron diseminados, y se hicieron inservibles. Estos desarrollos anteriores (a modo de investigación) a menudo probaban distintos enfoques para resolver distintos problemas, usualmente apresurados para entregar a término para una demostración, omitiendo documentación.
* Poltergeists, o Gipsy, o Proliferation of Classes, o Big DoIt Controller Class. Las clases poltergeists (fantasmas) se caracterizan por tener pocas responsabilidades dentro del sistema y un ciclo de vida bastante breve, ya que “aparecen” solamente para iniciar algún método en alguna clase, a menudo en un determinado orden. Son de relativa facilidad de encuentro ya que sus nombres suelen llevar el sufijo “controller” o “manager”. Estas clases desordenan el diseño ya que agregan abstracciones innecesarias, son excesivamente complejas, difíciles de mantener y comprender.
No hay comentarios:
Publicar un comentario