La tienda de animales V

 Una vuelta de tuerca más

Patrones Estructurales

Hola de nuevo a todos y todas. En esta quinta entrada sobre los patrones GOF empezaremos una nueva tarea de modelado e implementación ya que hemos visto todos los patrones Creacionales. 

En esta nueva etapa veremos los patrones Estructurales que se caracterizan porque solucionan aspectos de composición (agregración) de clases y objetos.

Lo que vamos a hacer es añadir nuevas clases al sistema ya existente o modificaremos las que ya tenemos para añadir nuevas funcionalidades y características.

Definición de las nuevas características del sistema

Nuestro sistema va a tener la facultad de conectarse a un servicio web de un proveedor para actualizar nuestro stock y poder realizar pedidos online. De esta forma podremos crear un módulo de Inventario con el stock de productos de la tienda y que podremos tener almacenado en una BD local y en una copia de respaldo online.

Además, se creará un sistema de contabilidad básico que lleve el balance de la tienda con las ventas del día. Este sistema de contabilidad será particular para cada tipo de tienda.

Otra linea de negocio que nuestra tienda ha iniciado recientemente es  el club de amigos en defensa de los animales. Para ello se ha puesto en contacto con una red de asociaciones del gremio y colaborará buscando a personas entre sus clientes que quieran adoptar o apadrinar a un animal. Pero lo curioso del caso es que algunos de estos animales provienen de circos que se han visto obligados a cerrar por la crisis y presentan un plus un tanto especial. Son animales virtuosos que pueden realizar cosas como por ejemplo cantar, bailar, tocar el piano, etc...

Diagrama de Clases

El diagrama con las nuevas clases que se deben añadir al sistema también presenta algunas de las clases del modelado anterior, pero con algunas modificaciones. Ya que los nuevos requerimientos amplian las funcionalidades de algunas clases ya existentes.

Justificación de los patrones elegidos y clases implicadas

• Adapter: Este patrón se utiliza cuando un cliente espera una interfaz determinada y la clase a utilizar presenta otra diferente, pero no la podemos cambiar porque por ejemplo, es un módulo externo compilado. Para solucionarlo se crea una nueva clase intermedia que añade un nivel de indirección con la misma interfaz que espera el cliente y se hace la petición a la interfaz adaptada. En nuestro ejemplo lo utilizaremos para acceder al webservice de un proveedor que nos envia su listado de artículos.

• WebMethodTarget: Es la clase abstracta con la interfaz que espera el cliente.
• WebMethodAdapter: la clase que implementa la interfaz.
• WebMethodAdaptee: la clase que tiene la interfaz a adaptar, o sea el webservice.

• Bridge: Permite desacoplar la interfaz de una funcionalidad de su implementación de forma que pueda cambiar sin modificarse la interfaz. Lo utilizaremos para representar el sistema de Balance de la tienda, ya al tener dos tipos de tienda, no tenemos que cambiar nada si modificamos la lógica del balance.

• Balance: Tiene la interfaz con un enlace a la implementación.
• SavageBalance, HomeBalance: el balance de cada tipo de tienda.
• BalanceImpl: La interfaz de la implementación.
• SavageBalanceImpl, HomeBalanceImpl: la implementación de la interfaz de la implementación.

• Composite: Este patrón nos permite hacer objetos complejos a partir de objetos simples o similares. Para nuestro caso lo usaremos para modelar el club de amigos de los animales. Las partes simples serían cada uno de los miembros y las complejas serían los grupos o subgrupos que se componen de estos miembros.

• Club: Tiene la interfaz para manejar las partes.
• Group: es la parte compleja del patrón que se compone de Member.
• Member: la parte simple del patrón.

• Decorator: Permite añadir funcionalidades de forma dinámica a un objeto, es decir, en tiempo de ejecución. De esta forma se reduce la complejidad del modelo ya que se elimina la necesidad de herencia y facilita modificar el modelo sin tener que tocar la implementación.  En el nuevo modelo se utilizará para dar respuesta a los animales que tienen talentos especiales. Evitaremos complicar la herencia del árbol Animal añadiendo una nueva clase TalentAnimal que se encargará de los nuevos requerimientos.

• Animal: A esta clase que ya estaba presente en el modelo inicial le queremos añadir nuevas funcionalidades. Ahora habrá animales que tienen talentos.
• Bird, Reptil, Feline, Canine: Se les ampliará su funcionalidad.
• TalentAnimal: Es la clase abstracta que tendrá la nueva funcionalidad.
• DanceAnimal, SingAnimal: Clases que implementarán TalentAnimal y que serán las clase que representarán las nuevas funcionalidades.

• Facade: Cuando tenemos un sistema con una gran complejidad ya que tiene multitud de clases y/0 su interacción es también alta podemos crear una clase Facade que haga de punto de entrada al sistema y de esta forma el cliente se abstrae del sistema y sólo utiliza la interfaz simplificada del mismo. Lo utilizaremos para modelar el inventario de la tienda que tiene una gran cantidad de clases y métodos.

• Inventory: es la clase facade que abstrae el sistema de inventario.
• ConnectionData: clase del sistema que crea la conexión a la BD.
• LoadData: obtiene el contenido de la BD.
• SaveData: almacena el inventario en la BD.

• Flyweight: elimina o reduce la redundancia de información cuando vamos a necesitar muchas instancias de objetos que tienen la misma información básica. Los Articles de nuestra tienda disponen de campos como pueden ser la referencia o la cantidad por lo que al tener que crear muchos Articles bajamos el coste en cuanto a memoria utilizada.

• Article: Es la clase abstracta con los campos comúnes.
• ConcreteArticle: una implementación de un Article.
• UnsharedConcreteArticle: otra implementación que no comparte información.
• ArticleFactory: la clase que se encarga de gestionar la creación y mantenimiento de las instancias de Article creadas.

• Proxy: Cuando necesitamos tener una representación de otro objeto porque la creación o el acceso al objeto real es muy costoso o presenta características especiales como por ejemplo la comprobación de permisos de acceso. En nuestro caso para poder modelar el acceso a la BD remota crearemos un proxy que representará una BD local y sólo accederá a la real cuando sea absolutamente necesario.

• DB: Es la interfaz común que comparten el objeto real de acceso a la base de datos y el Proxy.
• DBProxy: la clase que controla el acceso al objeto real SQLServer.
• SQLServer: es la clase de acceso a la BD real.

Hasta aquí llegamos con esta entrega y os invito a seguir la siguiente en la que nos adentraremos en la implementación es este nuevo modelo ampliado con los patrones estructurales.

Hasta pronto.