Universidad Tecnológica de la Sierra

Hidalguense
Dirección de Tecnologías de la Información y Comunicación

DESARROLLO DE APLICACIONES II

Clasificación de Patrones.

Alumno: Brandon Serrano Grez

Orientador: Alberto Corona Alejandro

 Contenido
Introducción. ............................................................................................................ 1
Desarrollo. ............................................................................................................... 2
Definición de Patrones. ........................................................................................ 2
Patrones Estructurales. ....................................................................................... 2
Adapter. ............................................................................................................... 2
Problema. ......................................................................................................... 2
Solución. .......................................................................................................... 2
Composite............................................................................................................ 3
Problema. ......................................................................................................... 3
Solución. .......................................................................................................... 3
Facade. ................................................................................................................ 4
Problema. ......................................................................................................... 4
Solución. .......................................................................................................... 4
MVC. .................................................................................................................... 5
Problema. ......................................................................................................... 5
Solución. .......................................................................................................... 5
Cuadro comparativo: Patrones Estructurales ...................................................... 6
Conclusión............................................................................................................... 7
Bibliografía. ............................................................................................................. 8

I
 Introducción.
En este documento se presentan los temas de patrones como técnicas para la
solución de problemas de diseño y sus características, así como la definición y
problema que resuelven de los patrones estructurales (adapter, composite, facade
y MVC) además de la comparación de cada patrón.

1
 Desarrollo.
Definición de Patrones.
Los patrones de diseño son soluciones para problemas típicos y recurrentes que
nos podemos encontrar a la hora de desarrollar una aplicación. Un patrón de diseño
es una descripción de clases y objetos comunicándose entre sí adaptada para
resolver un problema de diseño general en un contexto particular.
Aunque nuestra aplicación sea única, tendrá partes comunes con otras
aplicaciones: acceso a datos, creación de objetos, operaciones entre sistemas etc.
En lugar de reinventar la rueda, podemos solucionar problemas utilizando algún
patrón, ya que son soluciones probadas y documentadas por multitud de
programadores.

Patrones Estructurales.
Los patrones estructurales se enfocan en como las clases y objetos se componen
para formar estructuras mayores, los patrones estructurales describen como las
estructuras compuestas por clases crecen para crear nuevas funcionalidades de
manera de agregar a la estructura flexibilidad y que la misma pueda cambiar en
tiempo de ejecución lo cual es imposible con una composición de clases estáticas.

Adapter.
Problema.
Convertir la interfaz de una clase en otra interfaz esperada por los clientes. Permitir
que clases con interfaces incompatibles se comuniquen.

Solución.
Class Adapter:
Esta clase de adaptadores es menos utilizada porque utiliza herencia múltiple.
Crearemos una clase adaptador que herede de la clase o clases a adaptar, cuyos
métodos pueden ser sobrescritos. Además, el adaptador deberá implementar la
nueva interfaz que deseamos utilizar. La adaptación se realiza llamando a los
métodos del padre. No permite la adaptación de las subclases de la clase adaptada.
Object Adapter:
Creamos una clase adaptadora que contiene una instancia de la clase o clases a
adaptar. Para compatibilizar las clases, el adaptador hace llamadas a la instancia
del objeto u objetos a adaptar. Este adaptador funciona con la clase adaptada y
todas sus subclases.

2
 Composite.
Problema.
Construir objetos dentro de una estructura de árbol, de esta manera los objetos que
componen el árbol pueden tratarse de manera individual o como una composición de
objetos.

Solución.
El patrón Composite requiere mínimo de tres componentes para poder existir los
cuales son Componente, Leaf o Rama y Composite.
Component:
Generalmente es una interface o clase abstracta la cual tiene las operaciones
mínimas que serán utilizadas, este componente deberá ser extendido por los otros
dos componentes Leaf y Composite.
Leaf:
El leaf u hoja representa la parte más simple o pequeña de toda la estructura y este
extiende o hereda de Component.
Composite:
Aquí es donde está la magia de este patrón, ya que el composite es una estructura
conformada por otros Composite y Leaf, Composite tiene los métodos add y remove
los cuales nos permiten agregar objetos de tipo Component, Sin embargo, como
hablamos anteriormente, el Componente es por lo general un Interface o Clase
abstracta por lo que podremos agregamos objetos de tipo Composite o Leaf.

3
 Facade.
Problema.
El patrón FACADE simplifica el acceso a un conjunto de clases proporcionando una
única clase que todos utilizan para comunicarse con dicho conjunto de clases.

Solución.
La solución consiste en crear una clase fachada que proporcione la funcionalidad
de manera sencilla a nuestro sistema cliente. Dicha clase utilizará la clase compleja
o los distintos componentes de los sistemas requeridos y los ofrecerá por medio de
operaciones más simples.
Donde:
Client:
Representa al sistema que quiere hacer uso de la clase compleja o el conjunto de
subsistemas mediante la fachada.
Facade:
Clase fachada que trata de ofrecer la funcionalidad que demanda el cliente mediante
una interfaz sencilla donde, internamente, utiliza las clases complejas.
ComplicatedClassX:
Conjunto de clases que se necesitan utilizar y a las que se pretende dar un punto
de acceso sencillo mediante la fachada.

4
 MVC.
Problema.
El diseño de aplicaciones organizadas y escalables con sofisticadas interfaces.
Especifica que una aplicación consta de un modelo de datos, de información de
presentación y de información de control. El patrón requiere que cada uno de estos
elementos esté separado en distintos objetos.

Solución.
MVC está compuesto por los siguientes componentes que dan solución a este
modelo:
Modelo:
Esta capa representa todo lo que tiene que ver con el acceso a datos: guardar,
actualizar, obtener datos, además todo el código de la lógica del negocio,
básicamente son las clases Java y parte de la lógica de negocio.
Vista:
La vista tiene que ver con la presentación de datos del modelo y lo que ve el usuario,
por lo general una vista es la representación visual de un modelo (POJO o clase
java).
Controlador:
El controlador es el encargado de conectar el modelo con las vistas, funciona como
un puente entre la vista y el modelo, el controlador recibe eventos generados por el
usuario desde las vistas y se encargar de direccionar al modelo la petición
respectiva.
En ningún momento interactúa directamente la vista con el modelo, mantiene la
seguridad en una aplicación.

5
 Cuadro comparativo: Patrones Estructurales
Nombre Problema Solución Ventajas Desventajas
Adapter Convertir la interfaz de una clase en Para la solución se utilizan las siguientes clases y objetos:  Permite adaptar clases en dominios totalmente  Dependiendo de la implementación, el adaptador
otra interfaz esperada por los Class Adapter: Crearemos una clase adaptador que herede de la clase o diferentes. puede contener múltiples punteros que
clientes. Permitir que clases con clases a adaptar, cuyos métodos pueden ser sobrescritos. Además, el  Un único adaptador puede adaptar la funcionalidad de incrementen la complejidad del sistema.
interfaces incompatibles se adaptador deberá implementar la nueva interfaz que deseamos utilizar. La múltiples clases.  Un sólo adaptador no puede trabajar con una
comuniquen. adaptación se realiza llamando a los métodos del padre. No permite la  Facilidad para redefinir el comportamiento de la clase clase y sus hijos a la vez.
adaptación de las subclases de la clase adaptada. adaptada.  Dificultad para redefinir el comportamiento de la
Object Adapter: Creamos una clase adaptadora que contiene una instancia  Simplicidad (un sólo objeto, no hay punteros ni clase adaptada.
de la clase o clases a adaptar. Para compatibilizar las clases, el adaptador indirecciones adicionales).
hace llamadas a la instancia del objeto u objetos a adaptar. Este adaptador  Flexibilidad para que un sólo adaptador trabaje con
funciona con la clase adaptada y todas sus subclases. muchas clases a adaptar.
 Extensibilidad, puesto que se pueden añadir
funcionalidades a todas las clases adaptadas a la vez.
Composite Construir objetos dentro de una El patrón Composite requiere mínimo de tres componentes para poder existir  Permite tratamiento uniforme de objetos simples y  Es difícil restringir los tipos de los hijos.
estructura de árbol, de esta manera los cuales son Componente, Leaf o Rama y Composite. complejos, así como composiciones recursivas.  Las operaciones de gestión de hijos en los
los objetos que componen el árbol Component: Generalmente es una interface o clase abstracta la cual tiene  Simplifica el código de los clientes, que sólo usan una objetos simples pueden presentar problemas:
pueden tratarse de manera las operaciones mínimas que serán utilizadas, este componente deberá ser interfaz. seguridad frente a flexibilidad.
individual o como una composición extendido por los otros dos componentes Leaf y Composite.  Facilita añadir nuevos componentes sin afectar a los
de objetos. Leaf: El leaf representa la parte más simple o pequeña de toda la estructura clientes.
y este extiende o hereda de Component.
Composite: El composite es una estructura conformada por otros
Composite y Leaf, Composite tiene los métodos add y remove los cuales nos
permiten agregar objetos de tipo Component.

Facade El patrón FACADE simplifica el
acceso a un conjunto de clases
proporcionando una única clase que
todos utilizan para comunicarse con
dicho conjunto de clases.
MVC El diseño de aplicaciones
organizadas y escalables con
sofisticadas interfaces. Especifica
que una aplicación consta de un
modelo de datos, de información de
presentación y de información de
control. El patrón requiere que cada
uno de estos elementos esté
separado en distintos objetos.
La solución consiste en crear una clase fachada que proporcione la
funcionalidad de manera sencilla a nuestro sistema cliente. Dicha clase
utilizará la clase compleja o los distintos componentes de los sistemas
requeridos y los ofrecerá por medio de operaciones más simples.
Client: Representa al sistema que quiere hacer uso de la clase compleja o
el conjunto de subsistemas mediante la fachada.
Facade: Clase fachada que trata de ofrecer la funcionalidad que demanda
el cliente mediante una interfaz sencilla donde, internamente, utiliza las
clases complejas.
ComplicatedClassX: Conjunto de clases que se necesitan utilizar y a las
que se pretende dar un punto de acceso sencillo mediante la fachada.
MVC está compuesto por los siguientes componentes que dan solución a
este modelo:
Modelo: Esta capa representa todo lo que tiene que ver con el acceso a
datos: guardar, actualizar, obtener datos, además todo el código de la lógica.
Vista: La vista tiene que ver con la presentación de datos del modelo y lo
que ve el usuario, por lo general una vista es la representación visual de un
modelo.
Controlador: El controlador es el encargado de conectar el modelo con las
vistas, funciona como un puente entre la vista y el modelo, el controlador
recibe eventos generados por el usuario desde las vistas y se encargar de
direccionar al modelo la petición respectiva.
 La principal ventaja del patrón fachada consiste en
que, para modificar las clases de los subsistemas,
sólo hay que realizar cambios en la interfaz/fachada,
y los clientes pueden permanecer ajenos a ello.
 Los clientes no necesitan conocer las clases que
 hay tras la clase FACADE.
 Se pueden cambiar las clases “ocultadas” sin
 necesidad de cambiar los clientes.
 Simplifica el uso de sistemas complejos con tareas
redundantes.
 Oculta al cliente la complejidad real del sistema.
 Reduce el acoplamiento entre el subsistema y los
clientes.
 La implementación se realiza de forma modular.
 Sus vistas muestran información actualizada siempre.
 El programador no debe preocuparse de solicitar que
las vistas se actualicen, ya que este proceso es
realizado automáticamente por el modelo de la
aplicación.
 Cualquier modificación que afecte al dominio, como
aumentar métodos o datos contenidos, implica una
modificación sólo en el modelo y las interfaces del
mismo con las vistas, no todo el mecanismo de
comunicación y de actualización entre modelos.
 Las modificaciones a las vistas no afectan al modelo
de dominio, simplemente se modifica la
representación de la información, no su tratamiento.
 Como inconveniente, si se considera el caso de
que varios clientes necesiten acceder a
subconjuntos diferentes de la funcionalidad que
provee el sistema, podrían acabar usando sólo
una pequeña parte de la fachada, por lo que sería
conveniente utilizar varias fachadas más
específicas en lugar de una única global.
 Creamos clases para funcionalidad ya existente.
 Para desarrollar una aplicación bajo el patrón de
diseño MVC es necesario una mayor dedicación
en los tiempos iniciales del desarrollo.
 Normalmente el patrón exige al programador
desarrollar un mayor número de clases que, en
otros entornos de desarrollo, no son necesarias.
 MVC requiere la existencia de una arquitectura
inicial sobre la que se deben construir clases e
interfaces para modificar y comunicar los
módulos de una aplicación.
 MVC es un patrón de diseño orientado a objetos
por lo que su implementación es sumamente
costosa y difícil en lenguajes que no siguen este
paradigma.

6
 Conclusión.
Se puede concluir que este reporte sirvió como introducción para mejorar la
comprensión de los temas que posteriormente se verán en la unidad, de esta forma
mejorando el aprendizaje, conocimiento, dominio y desempeño del alumno, así
podrá aplicar estos patrones en futuros proyectos.

7
 Bibliografía.

http://siul02.si.ehu.es/~alfredo/iso/06Patrones.pdf

https://highscalability.wordpress.com/2010/04/12/patrones%C2%A0estructurales/

https://programacion.net/articulo/patrones_de_diseno_vii:_patrones_estructurales_-
_adapter_1008

https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o#Patrones_estructurales

https://www.oscarblancarteblog.com/2014/10/07/patron-de-diseno-composite/

https://programacion.net/articulo/patrones_de_diseno_xi_patrones_estructurales_facade_
1014