~Semana 9. Patrones de Diseño

Semana 9

Materia: Programación Orientada a Objetos

Martes M1-M3

Hola a todos, en esta entrada les hablaré sobre los patrones de diseño.

Abstact Factory 

El propósito de este patron de diseño proporciona un contacto para crear familias de objetos relacionados o dependientes sin tener que especificar su clase concreta.

Por ejemplo. 

Si tienes que administrar información de contactos con sus respectivos teléfonos y direcciones, como se hace en una agenda. Se tendrían que crear clases para administrar direcciones, números de teléfono y nombre de contactos. Estas clases tendrán que almacenar información de los contactos con ciertos formatos. Por ejemplo en Norteamérica todos los números de teléfono están limitados a 10 dígitos y el código postal también tiene cierto formato. 

También puede ser que administrando los contactos, algún contacto tenga números de teléfono de otros países, por ejemplo Holanda, en Holanda tienen diferentes reglas para los números de teléfono o direcciones válidas por lo que se tienen que realizar validaciones. Cada vez que se agreguen más y más contactos esto se irá extendiendo de más y más reglas y se tendrá que estar modificando y recompilando el código. 

Abstact Factory es una solución a este problema ya que con este patrón se define una clase AdressFactory para generar objetos que siguen un patrón general pata Address y PhoneNumber. En tiempo de ejecución esto se asocia con un número de fábricas para distintos países y cada país tiene su propia versión de las clases Address y PhoneNumber.

Este patrón es aplicado cuando:

• El cliente debe ser independiente del proceso de creación de los productos.
• La aplicación debe configurarse con una o más familias de productos.
• Es necesario crear los objetos como un conjunto, de forma que sean compatibles. 
• Desea proporcionar una colección de clases y únicamente quiere revelar sus contratos y relaciones, no sus implementaciones.

Ventajas y desventajas

Una Abstact Factory ayuda a incrementar la flexibilidad general de una aplicación. Durante el diseño, no se tiene que predecir todos los usos futuros de la aplicación, se crea un framework general y se desarrollan implementaciones independientes del resto de la aplicación. En tiempo de ejecución, la aplicación puede integrar fácilmente nuevas características y recursos.

Otra ventaja es que se puede simplificar la comprobación del resto de la aplicación. Implementando unas clases TestConcreteFactory y TestConcreteProduct puede servir para simular el comportamiento esperado de los recursos.

Si el producto abstracto no está definido apropiadamente, puede resultar difícil o incluso imposible generar productos concretos deseados.

Abstact Factory en mi Proyecto.  

Según lo que entendí y con este ejemplo que puse creo que podría utilizar este patrón de diseño en Dietas, ya que habrá diferentes tipos de dietas con diferentes formatos ya que algunas dietas tendrán ciertas excepciones, pienso que en la cuestión de los alimentos se puede utilizar este tipo de patrón. 

Prototype

Este patrón de diseño facilita la creación dinámica al definir clases las cuales sus objetos pueden crear copias de si mismos.

Aplicado a mi Proyecto.

Cuando se necesite copiar algún objeto con el fin de que el usuario no tenga que introducir manualmente toda la información cuando se crea un nuevo paciente por ejemplo. Una solución a este problema es.

Crear un nuevo objeto Paciente y copiar los valores del objeto Paciente existente.

La desventaja de este patrón es que viola el principio de encapsulación de la orientación a objetos, esto me hace estar un poco indecisa en usar o no usar este patrón. Para poder llegar a esta solución se tienen que hacer llamadas a métodos para copiar la información necesaria. Esto quiere decir que es más difícil mantener el código de la clase Paciente porque se extenderá en todo el proyecto. Además que también dificulta la reutilización de la clase Paciente.

Ventajas

El patrón de diseño Prototype es muy útil porque permite que los sistemas generen una copia de un objeto, con variables ya establecidas a un valor significativo.

Adapter

Este patron de diseño es de tipo estructural, sirve como intermediario entre dos clases, convirtiendo las interfaces de una clase para que pueda ser utilizada por otra.

Una de las ventajas de la programación orientada a objetos citada con mayor frecuencia es que permite la reutilización del código. Como los datos y el comportamiento se centralizan en una clase, puede mover una clase de un proyecto a otro y reutilizar su funcionalidad.

Por ejemplo, si estas realizando un gestor de información personal y un amigo de otro país decide cooperar contigo ya que tu amigo ha estado trabajando en un proyecto similar y puedes proporcionarle una implementación comercial de un sistema. Pero al momento de recibir los ficheros, la interfaz no corresponde con las interfaces que el ha estado utilizando en su aplicación y también puede que el código esté en otro idioma que el no conoce.

Tendrías dos soluciones posibles.

• La primera opción sería reescribir el componente para que implemente todas las interfaces requeridas. Reescribir el nuevo componente es algo menos recomendable porque tendrías que hacer esto mismo cada vez que recibas la última versión de tu amigo.
• La segunda opción es reescribir su propia aplicación y empezar a utilizar nuevas interfaces. La desventaja es que tendrías que recorrer todo su código para cambiar todas las ocurrencias de la interfaz antigua.

Lo que se necesita es un traductor -un componente que traduzca las llamadas de una interfaz en llamadas a otra interfaz distinta.

La verdad no se si esto aplique en mi proyecto, aunque si lo voy a comercializar sería bueno pensar en este tipo de patrón de diseño. 

Bueno, esto es todo de patrones de diseño, cualquier comentario ya saben pueden hacerlo :D saludos