Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Patrones Estructurales

No description
by

Mau Muñoz

on 16 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Patrones Estructurales

Alejandra Monge • Javier Meza • Mauricio Muñoz Patrones
Estructurales Adapter Bridge Composite Flyweight Proxy Facade Patrones de diseño Patrones Estructurales Agenda Conclusiones El objetivo de este patrón es proveer una interfaz unificada para un grupo de clases en un subsistema. Este patrón define una interfaz de alto nivel que hace el subsistema más fácil de usar. Consecuencias Ejemplo Aplicación IDE Ejemplo SIGERH Cuando se desea proveer una interfaz simple a un subsistema complejo.
Si existen muchas dependencias entre clientes y clases que pertenecen a cierta abstracción.
Si desea separar el sistema en subsistemas donde cada uno podría estar en diferentes capas. Objetivo Adaptar la interfaz/conexión de una clase en otra interfaz que esperan los clientes.
Ajustar una clase X a otra clase Y sin tener que modificar el código fuente de la clase X
Clases pertenecientes a una biblioteca, un API, etc.
Añadir alguna funcionalidad que la clase que se está reutilizando no proporciona. Cuándo utilizarlo Este patrón debe usarse cuando:

Se quiere usar una clase existente y su interfaz/conexión no concuerda con la que necesita
Crear una clase reutilizable que coopere con clases que no tienen por qué tener interfaces compatibles. Estructura básica Hay dos tipos de adaptadores: Estructura de un adaptador de clase, utiliza la herencia múltiple para adaptar una interfaz o conexión a otra: Estructura de un adaptador de objetos, se basa en la composición de objetos: Participantes Es la clase que adapta o cambia la interfaz/conexión de la clase adaptable a la interfaz/conexión deseada. Esta clase define la interfaz/conexión que debe utilizar el Cliente. Target Cliente Es la clase que colabora con los objetos que se ajustan a la interfaz/conexión que se desea, es decir la Objetivo. Adaptee Adapter Esta clase define interfaz/conexión existente que necesita ser adaptada, ajustarla, para poder utilizarla. Ventajas y Desventajas Un adaptador de clases se refiere a solo una clase adaptable concreta, no nos sirve si lo que queremos es adaptar una clase y todas sus subclases.
Tiene la ventaja de que la clase Adaptador redefine parte del comportamiento de la clase Adaptable, además introduce solo un objeto.
Un adaptador de objetos permite que un mismo Adaptador funcione con muchos Adaptables
Puede añadir funcionalidades a todos los Adaptables. Ejemplo Manejo de Solicitudes Ejemplos Estructura Cuándo utilizarlo Objetivo El objetivo de este patrón es proveer un suplente para otro objeto y de esta manera controlar el acceso al mismo y construirlo solo cuando sea estrictamente necesario. Objetivo Cuándo utilizarlo Tres casos: Proxy Remoto Cuando se necesita representar de manera local un objeto que está en otro espacio de dirección (un servidor web, por ejemplo) Proxy Virtual Cuando se deben crear objetos costosos solo cuando es estrictamente necesario Proxy de Protección Cuando se desea controlar el acceso a un objeto original (cuando estos objetos tienen diferentes permisos de acceso, por ejemplo) Estructura Comunicación entre clases involucradas: Ejemplo Editor de Documentos Ejemplo SIGERH Ejemplos Objetivo Describe como compartir objetos para permitir su uso con granularidades muy finas sin un costo prohibitivo.
Un objeto Flyweight (ligero) es un objeto compartido que puede usarse en varios contextos a la vez.
Modelan conceptos o entidades que normalmente son demasiado numerosas como para ser representados con objetos.
Se debe definir el estado intrínseco o extrínseco del objeto ligero Cuándo utilizarlo Este patrón debe usarse cuando:

Una aplicación utiliza un gran número de objetos
El costo de almacenamiento es elevado debido al gran número de objetos.
La mayor parte del estado del objeto puede hacerse extrínseco.
Muchos grupos de objetos pueden reemplazarse por pocos objetos compartidos.
La aplicación no depende de la identidad de un objeto Estructura El siguiente diagrama muestra cómo se comparten los objetos Flyweight: Participantes Puede haber subclases de Flyweight que no necesitan ser compartidas. Declara una interfaz por la cual los objetos ligeros pueden recibir su estado extrínseco y actuar sobre dicho estado. Flyweight ConcreteFlyweight Esta clase implementa la interfaz Flyweight y en ella se almacena el estado intrínseco del objeto ligero, representa al objeto ligero que se vaya a compartir. UnsharedContreteFlyweight FlyweightFactory Crea y controla los objetos flyweight, dichos objetos son almacenados en un pool (lista) de objetos flyweight, se apoya al patrón Singleton para crear nuevos objetos si no hay ninguno y si ya existe proporciona dicha instancia. Ventajas y Desventajas Objetos pueden introducir costos en tiempo de ejecución asociados con la transferencia, búsqueda y cálculo del estado extrínseco.
Se ve compensado con el ahorro en almacenamiento.
Este patrón suele usarse junto con el patrón Composite para representar una estructura jerárquica como un grafo con nodos compartidos. Ejemplo Desacoplar una abstracción de su implementación, de manera que ambas puedan variar de independientemente. Objetivo Se desea que tanto la abstracción como su implementación puedan variar de manera independiente
Los cambios en la implementación de una abstracción no deben impactar en los clientes
Las abstracciones o las implementaciones deben ser extensibles por medio de subclases. Cuándo utilizarlo Estructura Ejemplo Construir objetos complejos a partir de otros objetos más simples, esto lo logra por medio de la composición recursiva y una estructura en forma de árbol. Objetivo Cuándo utilizarlo Este patrón debe usarse cuando:

Se busca representar una jerarquía de objetos de tipo parte-todo.
Se busca que el cliente pueda ignorar la diferencia entre objetos primitivos y objetos compuestos, es decir, que pueda tratarlos de la misma manera.
Se desea definir una jerarquía entre clases Estructura Jerarquía Ejemplo Patrones de Diseño
Patrones Estructurales
Facade
Adapter
Bridge
Proxy
Flyweight
Composite
Conclusiones
Full transcript