Barra Sup Mobile


La oficina de proyectos de informática
pmoinformatica.com

Páginas

miércoles, 5 de diciembre de 2012

Errores comunes en el desarrollo de software: el Objeto Todopoderoso


Como continuación de la serie acerca de errores comunes en programación, desarrollo de software y base de datos, pasaremos a describir a continuación en sucesivos artículos una serie de errores comunes, también denominados "anti patrones". Los anti patrones representan herramientas útiles para aplicar las buenas prácticas de programación, pues estos describen "lo que no debe hacerse".

En esta entrega se describe el anti patrón del "Objeto Todopoderoso", también denominado "Clase Gorda" si nos referimos a una aplicación orientada a objetos, e inclusive en algunas referencias existe en la forma de la "Tabla Todopoderosa" para el caso de base de datos.

El anti patrón del "Objeto Todopoderoso"

Se presenta al diseñar objetos que poseen excesiva cantidad de funciones en la aplicación. Con frecuencia, contienen números atributos y métodos, siendo responsables de muchas partes de la lógica de negocio. Además, tienden a manejar información de una aplicación o programa completo.

El resultado, se obtiene una aplicación que en lugar de poseer objetos comunicándose entre ellos directamente, estos se hacen dependientes de la clase gorda para manejar la interacción entre ellos.

Tipo de anti patrón

Es un anti patrón de diseño de software.

Problemas asociados con este anti patrón
  • A menudo resulta que en muchas partes del código se hace referencia al objeto.
  • Como resultado, el mantenimiento se hace mucho más difícil.
  • Cualquier cambio en una funcionalidad individual impacta toda la aplicación.
  • Mayor extensión en las pruebas de regresión cuando se cambia alguna funcionalidad. Pues el objeto todopoderoso siempre estará afectado.
Situaciones en las que podrían justificarse

Cuando se está trabajando en entornos en los que el rendimiento y la centralización son más importantes que el mantenimiento y la elegancia en la programación. Sin embargo, en general, es considerado una mala práctica de diseño de software.

Solución / Alternativa

El patrón recomendado es diseñar objetos que cumplan el principio de responsabilidad única, en torno a las entidades relacionadas con objetos del negocio.

Por ejemplo, el diseñar un objeto denominado “Cliente” que ejecute todas las operaciones asociadas con este (Ingreso, Actualización, Consulta y Modificación) es preferible frente a crear un único objeto denominado “Consultas”, que centralice todas las consultas ejecutadas por cualquier entidad de negocio de la aplicación.

¿Y que opina usted?

¿Que opina usted del Objeto Todopoderoso?, ¿ha encontrado alguna vez la aplicación de este anti patron?, ¿Como rediseñaría el código como alternativa al anti patron?, ¿Que le diría a sus programadores para que no cometieran este error?.

Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” (http://oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica o al feed RSS del Blog.

<< Artículo anterior: Errores comunes en el desarrollo de bases de datos Tercera Parte


Acerca de artículos anteriores de esta serie


¿Interesado en libros sobre desarrollo de software?



























Transact SQL-DML Funciones y Bases 
de datos
Autor: Rocío Navarro Lacoba
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Código Limpio
Autor: Robert C. Martin
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Métodos ágiles y Scrum
Autor: Alonso Alvarez García y otros
>> España (amazon.es)
>> Latinoamérica (amazon.com)

Code Complete
Autor:
Steven C. McConnell
>> España (amazon.es)
>> Latinoámerica (amazon.com)


Novedades Amazon


Referencia:

Wikipedia. Antipatron de diseño
http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o

Wikipedia. Objeto Todopoderoso
http://es.wikipedia.org/wiki/Objeto_todopoderoso

Otros artículos en “La Oficina de Proyectos de Informática”

Gestión de desarrollo de software


>>10 actividades críticas a incluir en todo plan de desarrollo de un software


Desarrollo ágil, Scrum y Test Driven Development

>> Test Driven Development (TDD): Ventajas y desventajas

>> Los 5 valores de la programación extrema

>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)

>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente

>> Plantillas Scrum: historias de usuario y criterios de aceptación

>> El “Test Driven Development” (TDD): Desarrollo y pruebas de software bajo Scrum

>> Scrum de Scrum: Desarrollo ágil para grandes proyectos

>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum

>> Herramientas de software para gestión de proyectos de desarrollo ágil

>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos

>> Los Programas de Certificación del Scrum Alliance

>> Preguntas y respuestas sobre Scrum Alliance

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Metodologías de desarrollo ágil

Gerencia de Proyectos

>> Lo urgente y lo importante (2da Parte): Las 10 tareas rutinarias de un Gerente de Proyectos

>> Lo Urgente y lo importante en la Gestión de Proyectos

>> Gestión de Proyectos: 5 tareas clave para dirigir la fase de ejecución

>> 5 preguntas y respuestas sobre la identificación de riesgos

>> Como hacer el seguimiento de los riesgos en proyectos

>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012

>> Plantilla para documentar Lecciones Aprendidas

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Las reuniones de trabajo: más productividad, menos reuniones

>> El patrocinador (Sponsor) del proyecto: Rol que debe asumir y lo que no debe hacer

>> Como lidiar con implicados (stakeholders) problemáticos

>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)


No hay comentarios :

Publicar un comentario