Descargar la presentación
La descarga está en progreso. Por favor, espere
1
UNIVERSIDAD TECNOLÓGICA EMILIANO ZAPATA
PRESENTACIÓN DE PATRONES DE DISEÑO APLICACIONES II BAUTISTA TACUBA ANARELI ACTIVIDAD10
2
PATRONES DE DISEÑO Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
3
Un patrón de diseño es una solución a un problema de diseño
Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
4
OBJETIVOS DE LOS PATRONES
Proporcionar catálogos de elementos reusables en el diseño de sistemas software. Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario común entre diseñadores. Estandarizar el modo en que se realiza el diseño. Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
5
Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente. .La herencia ata una implementación a la abstracción permanentemente, lo que hace la hace difícil de modificar, extender y rehusar la implementación y la abstracción independientemente. La respuesta a esta flexibilidad esta en utilizar el patrón de diseño bridge.
6
ESTRUCTURA
7
PARTICIPANTES Abstraction define una interface abstracta. Mantiene una referencia a un objeto de tipo Implementor. RefinedAbstraction extiende la interface definida por Abstraction Implementor define la interface para la implementación de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser bastante diferente. Típicamente la interface Implementor provee sólo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas. ConcreteImplementor implementa la interface de Implementor y define su implementación concreta.
8
Builder Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
9
el patrón builder (Constructor) es usado para permitir la creación de una variedad de objetos complejos desde un objeto fuente (Producto), el objeto fuente se compone de una variedad de partes que contribuyen individualmente a la creación de cada objeto complejo a través de un conjunto de llamadas a interfaces comunes de la clase Abstract Builder.
10
A menudo, el patrón builder construye el patrón Composite, un patrón estructural.
Intención: Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto, de tal forma que el mismo proceso de construcción pueda crear representaciones diferentes.
11
diagrama
12
Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
13
Propósito El patrón de diseño Prototype (Prototipo), tiene como finalidad crear nuevos objetos duplicándolos, clonando una instancia creada previamente.
14
Solución Este patrón propone la creación de distintas variantes del objeto que nuestra aplicación necesite, en el momento y contexto adecuado. Toda la lógica necesaria para la decisión sobre el tipo de objetos que usará la aplicación en su ejecución debería localizarse aquí.
15
Luego, el código que utiliza estos objetos solicitará una copia del objeto que necesite. En este contexto, una copia significa otra instancia del objeto. El único requisito que debe cumplir este objeto es suministrar la prestación de clonarse. Cada uno de los objetos prototipo debe implementar el método Clone().
16
Esquema
17
Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
18
Facade, façade o fachada
es un patrón de diseño que sirve para proveer de una interfaz unificada sencilla que haga de intermediaria entre un cliente y una interfaz o grupo de interfaces más complejas.
19
Facade puede hacer una biblioteca de software más fácil de usar y entender, ya que facade implementa métodos convenientes para tareas comunes; hacer el código que usa la biblioteca más legible, por la misma razón; puede reducir la dependencia de código externo en los trabajos internos de una biblioteca, ya que la mayoría del código lo usa Facade, permitiendo así más flexibilidad en el desarrollo de sistemas; y puede envolver una colección mal diseñada de APIs con un solo API bien diseñado.
20
Problemas que soluciona
Problema: Un cliente necesita acceder a parte de la funcionalidad de un sistema más complejo. Definir una interfaz que permita acceder solamente a esa funcionalidad. Problema: Existen grupos de tareas muy frecuentes para las que se puede crear código más sencillo y legible. Definir funcionalidad que agrupe estas tareas en funciones o métodos sencillos y claros.
21
Problema: Una biblioteca es difícilmente legible.
Crear un intermediario más legible. Problema: Dependencia entre el código del cliente y la parte interna de una biblioteca. Crear un intermediario y realizar llamadas a la biblioteca sólo o, sobre todo, a través de él. Problema: Necesidad de acceder a un conjunto de APIs que pueden además tener un diseño no muy bueno. Crear una API intermedia, bien diseñada, que permita acceder a la funcionalidad de las demás. Cuidado: Facade debe utilizarse para crear clases sencillas, no clases que "sirvan para todo" o "lo hagan todo".
22
Problema: Necesidad de acceder a un conjunto de APIs que pueden además tener un diseño no muy bueno.
Crear una API intermedia, bien diseñada, que permita acceder a la funcionalidad de las demás. Cuidado: Facade debe utilizarse para crear clases sencillas, no clases que "sirvan para todo" o "lo hagan todo".
23
ESQUEMA
Presentaciones similares
© 2025 SlidePlayer.es Inc.
All rights reserved.