viernes, 1 de junio de 2007

El Patrón Decorador

El decorador describe una solución al problema de agregar una funcionalidad a un objeto sin cambiar realmente el código en el objeto.
La definición formal del decorador, dada por el "GoF" es:

"Adjuntar responsabilidad adicional a un objeto dinámicamente."

La necesidad de cambiar dinámicamente la funcionalidad o comportamiento de un objeto surge típicamente en una de estas dos situaciones. Primero, cuando el código fuente del objeto está no disponible, puede ser que el objeto es un control ActiveX o una biblioteca de clases de terceras partes está utilizada. Segundo, cuando la clase que es ampliamente utilizada para la responsabilidad específica, se necesita sólo en una o más situaciones

La principal diferencia entre usar subclases y el patrón Decorador es que con las subclases se trabaja directamente con la clase, en cambio con el patrón Decorador se modifican los objetos dinámicamente. Cuando se extiende una clase, los cambios hechos a las clases hijos serán afectados a todas las instancias de las clases hijos; sin embargo, con el patrón Decorador se aplican los cambios a cada objeto individual que se quiere cambiar.

Estructura del patrón Decorador





A continuación describiremos la estructura:

Componente: Clase abstracta común a todas las clases susceptibles de ser ampliadas con el Decorador.

ComponenteConcreto: Son las clases cuya funcionalidad se puede extender y en las que se delega en última instancia para realizar las operaciones propias de la clase.

Decorator: Clase abstracta que declara la estructura común a todos los Decoradores y declara (o implementa, según sea el caso) la responsabilidad de mantener una referencia al objeto que se extiende. Es posible que sobrecargue todos los métodos de la clase Componente con llamadas al componente concreto, de forma que aquellos métodos cuya funcionalidad no se extiende simplemente llaman a los originales.

DecoradorConcreto1 y DecoradorConcreto2: Son clases concretas que heredan de Decorator e implementan las extensiones de funcionalidad de la clase original ComponenteConcreto.


Este patrón es en realidad un puente extendido. Debido a que el cliente está afectado, puede dirigir el objeto decorador como si realmente fuera la implementación al final del puente estándar, porque la interfaz de los dos es la misma. Debido a que la implementación está afectada, la petición mira exactamente igual que si fuera directamente desde el cliente. No necesita nunca conocer que incluso que el decorador existe.
En los próximos dos artículos veremos como se implementa este patrón en VFP y C# extendiendo el ejemplo del patrón puente que venimos tratando en artículos anteriores.

No hay comentarios.: