![]() |
Discusión sobre Patrones de diseño
Buenos días compañeros,
Abro este espacio con la finalidad de empezar una serie de “artículos” que muchas veces oímos y que pocas tomamos en cuenta cuando asumimos un diseño orientado a objetos. Me refiero a los patrones. Si, a esos mismos artículos técnicos tanto cuestionados sobre si vale la pena tomarlos en cuenta o si es preferible ignorarlos y hacer nuestros diseños asistidos por la prisa y el método del bombero: apagar incendios. Antes de comenzar, este primer post está destinado a dar a conocer los objetivos que pretendo con esto:
Mi idea es destinar el segundo post para dar a conocer algunas breves normas, mejor dicho recomendaciones, para que nos entendamos y establecer un orden. El tercero, a modo de índice, contendrá los enlaces a los artículos donde se de comienzo a un nuevo patrón. El cuarto destinarlo para dar inicio sobre el primero de los patrones que estoy preparando: Adaptador. De allí en adelante, se invita a la comunidad a seguir “posteando” y así formar un buen debate sobre el tema. Están todos cordialmente invitados a redactar el artículo, los ejemplos y el tema de debate. Y si es necesario modificar algún artículo y/o ejemplo siéntanse cómodos de hacerlo. Este lugar no se construye sólo. Muchas gracias. |
Sugerencias
He aquí, algunos puntos a considerar al momento de postear en este hilo:
Sobre los artículos de discusión:
Cita:
|
Indice
He aquí el temario que tenemos actualmente:
Cita:
Cita:
|
Patrón: Adaptador
Introducción
Algo que no está bien explicado en UML y Patrones es la relación de dependencia entre el Adaptador y el Adaptado. Desde otras fuentes consultadas me he percatado que existen dos enfoques de conseguir esta adaptación: Adaptador de Objeto Valiéndonos de la composición, el adaptador contiene una instancia de la clase adaptada. En esta situación, el Adaptador envía las llamadas a la instancia del objeto envuelto. Gracias a esto, la encapsulación se mantiene y todo el acoplamiento se da entre estas dos clases y no hacia "afuera". Y como señalan las fuentes bibliográficas, este tipo de Adaptador es útil cuando no se puede usar (o mejor dicho no es deseable) la herencia. Los motivos más básicos pueden deberse a que estamo intregando la clase a una jerarquía y ya estamos herendando de una clase base. Como también pueden deberse a que deseamos evitarnos la herencia de algunos métodos que no son compatibles o deseables a nuestros diseños. Para mi, lo que quería decir Larman en su texto, quedaría así: Leyendo el About.com me da la impresión de que pareciera haber un tercer tipo de adaptador, al que denomina Adaptador por polimorfismo. Pero otras referencias no mencionan esto. Más bien yo lo encuentro como un caso particular de este enfoque, sobre todo por lo dicho antes: Cita:
De modo que se consiga llamar al método que encapsula Adaptado, desde su Adaptador:
Esto me da pie, para el segundo enfoque de implementar un Adaptador. Adaptador de Clase Consiste en que la clase que implementa la nueva interfaz extienda de la original, añadiendole los métodos necesarios. Con esto, la nueva interfaz se convierte en una adecuada para el Cliente. Este enfoque es útil cuando el Adaptado posee las funcionalidades requieridas pero no ofrece una "interfaz" totalmente acorde a lo necesitado. De este modo, heredando de éste podemos implementar los métodos apropiados en el Adaptador para que se adapten los métodos heredados. Si uno estos conceptos por lo dicho por Craig Larman, estaríamos en una situación como la siguiente: Esta es una solución elegante, pero en en Delphi que no permite herencia "privada", expone los métodos de la clase Adaptado. Y en ciertas circunstancias esto no es muy deseable. Una solución que propone Zarko en sus artículos es la publicar los métodos que se heredan e invalidarlos. Como por ejemplo:
Pero a mi gusto, no es muy agradable este comportamiento. Por lo general, me parece deseable aplicar el primer enfoque. Para ir finalizando esta "exposición", el artículo disponible en Wikipedia (español) ofrece a modo de resumen las ventajas y desventas que posee para tipo. Al final del texto puede encontrar la bibliografía. Wiki El artículo wiki que trata el tema está disponible en el siguiente enlace. Invito a los foristas a compartir de su lectura y aportaciones. Ejemplos He prepatado, hace un tiempo, unos ejemplos de práctica sobre el exquisito patrón. Las demos están a su disposición en la sección FTP: Adaptador de objeto Adaptador de polimorfismo Adaptador de clase Los ejemplos han sido basados en los artículos de Zarko Gajic con la finalidad de que el "salto" entre estas lecturas no sea tan brusco. Se reciben ideas y si es necesario preparar ejemplos más funcionales y reales puede aportarlos y serán añadidos aquí. No se ha pretendido realizar código 100% útil la idea es mostrar en forma simple como aplicar el concepto del patrón. Referencias UML y Patrones. Una introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. Segunda Edición. Ed. PEARSON - Prentice Hall. Autor: Craig Larman. About.com - The Adapter Pattern - Delphi OOP Part 10 - Chapter 22 About.com - The Adapter Pattern - Delphi OOP Part 10 - Chapter 23 Wikipedia (Español) – Adapter (patrón de diseño) Wikipedia (Inglés) – Adapter pattern Programación.com - Artículos – Diseño de software con patrones (parte 4) Cita:
Muchas gracias a todos por su tiempo. Espero que le haya sido de agrado.:) Estoy enormemente agradecido con Emilio por brindar este espacio. Sin él, y el resto de la comunidad estos artículos no hubieran salido a la luz. |
La franja horaria es GMT +2. Ahora son las 09:34:08. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi