PDF de programación - Patrones de Diseño, Refactorización y Antipatrones. Ventajas y Desventajas de su Utilización en el Software Orientado a Objetos

Cuadernos de la Facultad n. 4, 2009

Patrones de Diseño, Refactorización y Antipatrones.
Ventajas y Desventajas de su Utilización en el Software
Orientado a Objetos


Gustavo Damián Campo*

[email protected]


Resumen

El presente artículo busca introducir al lector en los conceptos de
Patrón de Diseño, Refactorización y Antipatrón, y cuáles son las
ventajas y desventajas inherentes a su aplicación en el desarrollo de
software orientado a objetos. Este no es un artículo sobre orientación a
objetos, por lo que no se tratan temas como herencia, polimorfismo y
encapsulamiento, entre otros.

Palabras Claves: Patrones de Diseño, Patrones, Refactorización,
Antipatrones

1. Introducción

A lo largo de los años la ingeniería de software fue introduciendo
nuevas técnicas en pos de obtener software de mejor calidad, tales
como las técnicas estructuradas, los lenguajes de cuarta generación,
las herramientas CASE, la orientación a objetos y nuevos modelos de
calidad.
Investigadores académicos y profesionales desarrollaron
distintos enfoques innovadores para la construcción de software, desde
el uso de nuevas tecnologías hasta la aplicación de nuevos procesos.
Incluso con todas estas ideas, el éxito de un producto software nunca
estuvo garantizado.


* El autor es Ingeniero en Informática por la Universidad Católica de Salta, Subsede Buenos Aires.
En el ámbito laboral, se dedica al desarrollo de software. El presenta artículo es una síntesis de su
trabajo de tesis.



101

Campo: Patrones de Diseño, Refactorización y Antipatrones

Casi todos los sistemas entregados son, en mayor o menor
medida, sistemas diseñados para un determinado propósito y con poca
flexibilidad, lo que se conoce como stovepipe systems, sistemas que no
pueden adaptarse al cambio. Este factor debe considerarse siempre ya
que el grado de flexibilidad de un producto software está directamente
relacionado con la calidad del mismo.

Si bien

la orientación a objetos mejora

la productividad,
adaptabilidad y reutilización del software, los sistemas orientados a
objetos con muchas líneas de código son difíciles de mantener y
extender con nueva funcionalidad. Esto no quiere decir que conceptos
tales como herencia, encapsulamiento o polimorfismo no sean
adecuados, sino que por sí solos no son suficientes. Estas técnicas
deben combinarse con otras de mayor nivel para poder obtener
software flexible, pero para poder hacerlo hace falta algo: experiencia.
Es esta experiencia la que hace que los expertos resuelvan nuevos
problemas mediante la aplicación de resoluciones que funcionaron con
anterioridad para problemas similares.

A la hora de recolectar experiencia, se pueden armar dos grandes

grupos: las buenas y las malas:

• Los Patrones de Diseño se corresponden con

las buenas
experiencias, ya que reúnen resoluciones a problemas recurrentes
encontrados en el diseño de software orientado a objetos.

• Los Antipatrones, por su parte, se corresponden a las malas
experiencias ya que reúnen soluciones que han producido efectos
negativos. Los Antipatrones proveen dos soluciones: la problemática
(aquélla con el impacto negativo), y la refactorizada (aquélla que
transforma la situación negativa en una más saludable).

Como se dijo anteriormente,

la utilización de herencia,
encapsulamiento y polimorfismo debe combinarse con técnicas de
mayor nivel. Estas técnicas de mayor nivel son: los Patrones de Diseño,
para obtener software flexible; los Antipatrones para evitar cometer
asegurar
errores
reorganizaciones ordenadas de código
la
mantenibilidad, o salir de algún Antipatrón.

fuente para mejorar

la Refactorización

para

recurrentes;

y

El inicio de los Patrones de Diseño suele atribuirse a un profesor
de arquitectura de la Universidad de Berkeley llamado Christopher
Alexander. A Pattern Language (1977) y The Timeless Way of Building

102

Cuadernos de la Facultad n. 4, 2009
(1979) presentaron la visión del autor sobre problemas recurrentes que
existían en la arquitectura de pueblos, ciudades y en cualquier tipo de
construcción. Estos problemas y soluciones fueron descriptos por
Alexander como “patrón”.

El trabajo de Alexander despertó el interés en el tema por parte de
la comunidad de programadores de software orientado a objetos y
dentro de la siguiente década comenzaron los desarrollos de patrones
para el diseño de software.

Con el correr de los años, los patrones fueron ganando aceptación
y se han ido extendiendo a diversas áreas de la construcción de
software.

Patrones de Diseño y Antipatrones brindan una forma efectiva de
compartir experiencia. Sea cual sea el lenguaje de programación
utilizado, las lecciones aprendidas pueden recolectarse con el fin de ser
compartidas con otros desarrolladores. A largo plazo, esto podría
mejorar la industria de desarrollo de software.



2. 2 Patrones de diseño

Un Patrón de Diseño (design pattern) es una solución repetible a
un problema recurrente en el diseño de software. Esta solución no es
un diseño terminado que puede traducirse directamente a código, sino
más bien una descripción sobre cómo resolver el problema, la cual
puede ser utilizada en diversas situaciones. Los patrones de diseño
reflejan todo el rediseño y remodificación que los desarrolladores han
ido haciendo a medida que intentaban conseguir mayor reutilización y
flexibilidad en su software.

Los patrones documentan y explican problemas de diseño, y luego
discuten una buena solución a dicho problema. Con el tiempo, los
patrones comienzan a incorporarse al conocimiento y experiencia
colectiva de la industria del software, lo que demuestra que el origen de
los mismos radica en la práctica misma más que en la teoría.

En (Gamma et al, 1995) se cita la definición de Christopher
Alexander sobre patrones: “cada patrón describe un problema que
ocurre una y otra vez en nuestro entorno, así como la solución a ese
problema, de tal modo que se pueda aplicar esta solución un millón de
veces, sin hacer lo mismo dos veces”. Si bien ésta definición es sobre



103

Campo: Patrones de Diseño, Refactorización y Antipatrones
patrones de ciudades y edificios la idea es aplicable a la industria del
software: encontrar una solución a un problema dentro de un contexto.

Un patrón de diseño nomina, abstrae e identifica los aspectos
clave de una estructura de diseño común, lo que los hace útiles para
crear un diseño orientado a objetos reutilizable. El patrón de diseño
identifica
roles y
colaboraciones, y la distribución de responsabilidades. Cada patrón de
diseño se centra en un problema concreto, describiendo cuándo
aplicarlo y si
teniendo en cuenta otras
restricciones de diseño, así como las consecuencias, ventajas e
inconvenientes de su uso.

instancias participantes, sus

las clases e

tiene sentido hacerlo

En los últimos años los patrones han ido ganando aceptación, y se
fueron extendiendo a otras áreas dentro del desarrollo y mantenimiento
de software. Su utilización, si bien todavía le queda mucho camino por
recorrer, comienza a tener suficiente madurez.

Los patrones de diseño proveen una forma efectiva para compartir
experiencia con la comunidad de programadores de software orientado
a objetos.

2.1. Componentes

Para que una solución sea considerada un patrón debe poseer

ciertos componentes fundamentales:

• Nombre del patrón. Permite describir en pocas palabras un problema

de diseño junto con sus soluciones y consecuencias.

• Problema (o fuerzas no balanceadas). Indica cuándo aplicar el
patrón. En algunas oportunidades el problema incluye una serie de
condiciones que deben darse para aplicar el patrón. Muestra la
verdadera esencia del problema. Este enunciado se completa con un
conjunto de fuerzas, término que se utiliza para indicar cualquier
aspecto del problema que deba ser considerado a la hora de
resolverlo, entre ellos:

- Requerimientos a cumplir por la solución.
- Restricciones a considerar.
- Propiedades deseables que la solución debe tener.

104

Cuadernos de la Facultad n. 4, 2009
Son las fuerzas las que ayudan a entender el problema dado que lo
exponen desde distintos puntos de vista.

• Solución. No describe una solución o implementación en concreto,
sino que un patrón es más bien como una plantilla que puede
aplicarse en diversas situaciones diferentes. El patrón brinda una
descripción abstracta de un problema de diseño y cómo lo resuelve
una determinada disposición de objetos. Que la solución sea
aplicable a diversas situaciones denota el carácter “recurrente” de los
patrones.

• Consecuencias. Resultados

inconvenientes.

en

términos

de

ventajas

e


2.2. Tipos

Según el nivel de abstracción los patrones de diseño pueden

clasificarse de la siguiente forma:

• Patrones arquitectónicos. Centrados en la arquitectura del sistema.
Definen una estructura fundamental sobre la organización del
sistema. Proveen un conjunto predefinido de subsistemas, cuáles
son sus responsabilidades y como se interrelacionan.

• Patrones de diseño. Esquemas para refinar los subsistemas o
componentes de un sistema de software, o sus relaciones. Describen
una estructura recurrente y común de componentes comunicantes
que resuelven un problema de diseño dentro de un contexto.
Ejemplo: el patrón singleton asegura que exis