SEARCH
You are in browse mode. You must login to use MEMORY

   Log in to start

IS 2 patrones


🇪🇸
In Spanish
Created:


Public


0 / 5  (0 ratings)



» To start learning, click login

1 / 25

[Front]


Transfer Proposito:
[Back]


Independizar el intercambio de datos entre capas. Representan los elementos del modelo de dominio

Practice Known Questions

Stay up to date with your due questions

Complete 5 questions to enable practice

Exams

Exam: Test your skills

Test your skills in exam mode

Learn New Questions

Popular in this course

Learn with flashcards

Dynamic Modes

SmartIntelligent mix of all modes
CustomUse settings to weight dynamic modes

Manual Mode [BETA]

Select your own question and answer types
Other available modes

Complete the sentence
Listening & SpellingSpelling: Type what you hear
multiple choiceMultiple choice mode
SpeakingAnswer with voice
Speaking & ListeningPractice pronunciation
TypingTyping only mode

IS 2 patrones - Leaderboard

0 users have completed this course. Be the first!

No users have played this course yet, be the first


IS 2 patrones - Details

Levels:

Questions:

59 questions
🇪🇸🇪🇸
Transfer Proposito:
Independizar el intercambio de datos entre capas. Representan los elementos del modelo de dominio
Factoria abstracta Proposito:
Proporciona interfaz para crear familia de objetos relacionados o que dependen entre si, sin especificar clases concretas
Factoria Abstracta motivacion
Si queremos tener interfaz de usuario independiente de los objetos concretos que la componen. Si aplicacion crea instancias de clases de la interfaz de usuario seria difícil cambiarla mas tarde.
Cuando aplicamos factoria abstracta?
Lo aplicamos cuando: - Sistema deba ser independiente de como se crean, componen y representan sus productos - Sistema debe ser configurado con familia de productos de entre varias - Familia de objetos producto relacionados esta diseñada para ser usada en cjto obligatoriamente, al ser requisito - Quiere proporcionar biblioteca de clases de productos y solo quiere revelar sus interfaces sin sus implementaciones.
Pros y Cons de factoria abstracta
Ventajas: - Aisla clases concretas de clientes - Facilita intercambio de familias de productos - Promueve la consistencia entre productos Inconvenientes: - Dibifil dar cabida a nuevos tipos de productos pues habría que modificar la factoría
Pros y cons de singleton
Ventajas: - Acceso controlado a unica instancia - Espacio de nombres reducido - Permite refinamiento de operaciones y la representación - Permite numero variable de instancias - Mas flexible que operaciones static Inconvenientes: - Dista mucho de ser evidente
Proposito de observador
Proposito: define dependencia de uno a muchos objetos, de forma que cuando un objeto cambie de estado se notifique y se actualicen automáticamente todos los objetos que dependen de el.
Motivacion de observador
Motivación: si se divide un sistema en una colección de clases cooperantes se deben mantener la consistencia entre estados relacionados. Esta consistencia no debe pagarse con un fuerte acoplamiento.
Cuando aplicamos observador?
Lo aplicamos cuando: - Una abstracción tiene dos aspectos y uno depende del otro - Cuando un cambio en un objeto requiere cambiar otros y no sabe cuantos objetos necesitan cambiarse - Cuando un objeto debería ser capaz de notificar a otros sin hacer suposiciones sobre quienes son dichos objetos.
Pros y cons de observador
Ventajas: - Permite modificar objetos y observadores independientemente - Acoplamiento abstracto entre sujeto y observador - Capacidad de comunicación mediante difusión Inconvenientes: - Actualizaciones inesperadas - Protocolo de actualización simple
Transfer
Proposito: independizar intercambio de datos entre capas Motivación: Si independizamos capas, no pueden tener conocimiento de la representación de entidades del sistema en cada capa. Lo aplicamos cuando: no representemos entidad en una capa
SERVICIO DE APLICACION
Proposito: centraliza logica del negocio Motivación: poner la logica del negocio en algún lado que no sea controlador o Dao. Lo aplicamos cuando: quiera representar logica del negocio que actúese sobre distintos objetos del negocio, agrupar funcionalidades relacionadas o encapsular logica no representada por objetos.
DAO
Proposito: acceder a capa de recursos proporcionando representación OO a los clientes Motivación: poder cambiar capa de recursos sin afectar a capa de negocio solo actualizando la capa de integración que es mas ligera que la de negocio. Lo aplicamos cuando: queremos independizar representación y el accesos a los datos de su procesamiento.
FACTORIA ABSTRACTA
Proposito: proporciona interfaz para crear familia de objetos relacionados o que dependen entre si, sin especificar clases concretas Motivación: si queremos tener interfaz de usuario independiente de los objetos concretos que la componen. Si aplicacion crea instancias de clases de la interfaz de usuario seria difícil cambiarla mas tarde. Lo aplicamos cuando: - Sistema deba ser independiente de como se crean, componen y representan sus productos - Sistema debe ser configurado con familia de productos de entre varias - Familia de objetos producto relacionados esta diseñada para ser usada en cjto obligatoriamente, al ser requisito - Quiere proporcionar biblioteca de clases de productos y solo quiere revelar sus interfaces sin sus implementaciones. Ventajas: - Aisla clases concretas de clientes - Facilita intercambio de familias de productos - Promueve la consistencia entre productos Inconvenientes: - Dibifil dar cabida a nuevos tipos de productos pues habría que modificar la factoría
SINGLETON
Proposito: garantiza que solo hay una instancia de una clase, proporcionando un único punto de acceso a ella. Esta instancia se puede redefinir mediante herencia. Ventajas: - Acceso controlado a unica instancia - Espacio de nombres reducido - Permite refinamiento de operaciones y la representación - Permite numero variable de instancias - Mas flexible que operaciones static Inconvenientes: - Dista mucho de ser evidente
OBSERVADOR
Proposito: define dependencia de uno a muchos objetos, de forma que cuando un objeto cambie de estado se notifique y se actualicen automáticamente todos los objetos que dependen de el. Motivación: si se divide un sistema en una colección de clases cooperantes se deben mantener la consistencia entre estados relacionados. Esta consistencia no debe pagarse con un fuerte acoplamiento. Lo aplicamos cuando: - Una abstracción tiene dos aspectos y uno depende del otro - Cuando un cambio en un objeto requiere cambiar otros y no sabe cuantos objetos necesitan cambiarse - Cuando un objeto debería ser capaz de notificar a otros sin hacer suposiciones sobre quienes son dichos objetos. Ventajas: - Permite modificar objetos y observadores independientemente - Acoplamiento abstracto entre sujeto y observador - Capacidad de comunicación mediante difusión Inconvenientes: - Actualizaciones inesperadas - Protocolo de actualización simple Las vistas son una especia de observadores del modelo , controlador maneja vistas con update(int evento, Object obj) y actualiza a una única vista cada vez. Controlador especie de observador de vistas.
Proposito
Proporciona interfaz para crear familia de objetos relacionados o que dependen entre si, sin especificar clases concretas
Motivacion
Si queremos tener interfaz de usuario independiente de los objetos concretos que la componen. Si aplicacion crea instancias de clases de la interfaz de usuario seria difícil cambiarla mas tarde.
Lo aplicamos cuando
- Sistema deba ser independiente de como se crean, componen y representan sus productos - Sistema debe ser configurado con familia de productos de entre varias - Familia de objetos producto relacionados esta diseñada para ser usada en cjto obligatoriamente, al ser requisito - Quiere proporcionar biblioteca de clases de productos y solo quiere revelar sus interfaces sin sus implementaciones.
Ventajas
- Aisla clases concretas de clientes - Facilita intercambio de familias de productos - Promueve la consistencia entre productos
Inconvenientes
- Dibifil dar cabida a nuevos tipos de productos pues habría que modificar la factoría
Proposito
Garantiza que solo hay una instancia de una clase, proporcionando un único punto de acceso a ella. Esta instancia se puede redefinir mediante herencia.
Motivacion
Necesario que algunas clases tengan una sola instancia y que sea la propia clase responsable de ella
Lo aplicamos cuando
-Solo debe haber una instancia de la clase y debe ser accesible a los clientes desde un punto de acceso conocido -La unica instancia debe ser extensible por herencia, y los clientes pueden usar la instancia extendida sin modificar su codigo
Pros
- Acceso controlado a unica instancia - Espacio de nombres reducido - Permite refinamiento de operaciones y la representación - Permite numero variable de instancias - Mas flexible que operaciones static
Cons
- Dista mucho de ser evidente
Proposito
Define dependencia de uno a muchos objetos, de forma que cuando un objeto cambie de estado se notifique y se actualicen automáticamente todos los objetos que dependen de el.
Lo aplicamos cuando
- Una abstracción tiene dos aspectos y uno depende del otro - Cuando un cambio en un objeto requiere cambiar otros y no sabe cuantos objetos necesitan cambiarse - Cuando un objeto debería ser capaz de notificar a otros sin hacer suposiciones sobre quienes son dichos objetos.
Pros
- Permite modificar objetos y observadores independientemente - Acoplamiento abstracto entre sujeto y observador - Capacidad de comunicación mediante difusión
Cons
- Actualizaciones inesperadas - Protocolo de actualización simple
Motivacion
Si se divide un sistema en una colección de clases cooperantes se deben mantener la consistencia entre estados relacionados. Esta consistencia no debe pagarse con un fuerte acoplamiento.
Proposito
Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar
Motivacion
-Estructurar un sistema en subsistemas ayuda a reducir la complejidad – Un objetivo clásico en diseño es minimizar la comunicación y dependencias entre subsistemas – Un modo de lograr esto es introduciendo un objeto fachada que proporcione una interfaz única y simplificada para los servicios más generales del subsistema
Aplicar cuando
- Queramos proporcionar una interfaz simple para un subsistema complejo - Haya muchas dependencias entre los clientes y las clases que implementan una abstracción - Queramos dividir en capas nuestros subsistemas
Pros
- Oculta a los clientes los componentes del subsistema, reduciendo así el número de objetos con los que traten los clientes y haciendo que el subsistema sea más fácil de usar - Promueve un débil acoplamiento entre el subsistema y los clientes - No impide que las aplicaciones utilicen clases del subsistema si es necesario
Cons
- Nuevas operaciones de los componentes deben promocionar hacia la interfaz de la fachada
NA
NA
Proposito
Evita acoplar el emisor de una petición a su receptor, dando a más de un objeto la posibilidad de responder a la petición. Encadena los objetos receptores y pasa la petición a través de una cadena hasta que es procesada por algún objeto
Pros
- Reduce el acoplamiento - Añade flexibilidad para asignar responsabilidades a objetos
Cons
No se garantiza la recepción de la petición
Proposito
Compone objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos
Pros
- Define jerarquías de clases formadas por objetos primitivos y compuestos - Permite un tratamiento uniforme por parte del cliente - Facilita añadir nuevos tipos de componentes
Cons
Oculta los tipos de los objetos dentro del compuesto
Proposito
Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con diferentes peticiones, hacer cola o llevar un registro de las peticiones, y poder deshacer las operaciones
Pros
Desacopla el objeto que invoca la accion que aquel que sabe como realizarla Las ordenes son objetos de primera clase Se pueden ensamblar ordenes en una orden compuesta Es facil añadir nuevas ordenes ya que no hay que cambiar las clases
Proposito
Define un objeto que encapsula cómo interactúan una serie de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente
Pros
Reduce la herencia Desacopla a los colegas Simplifica los protocolos de los objetos Abstrae cómo cooperan los objetos
Cons
Centraliza el control
Proposito
– Convierte la interfaz de una clase en otra interfaz que es la que esperan los clientes – Permite que cooperen clases que de otra forma no podrían tener interfaces compatibles
Pros
Permite que el adaptador redefina parte del comportamiento del adaptable al ser subclase suya Introduce un solo objeto y no se necesita ningun puntero de indireccion adicional para obtener el objeto adaptado
Cons
La adaptación es de una clase pero no de sus subclases
Proposito
Asigna responsabilidades adicionales a un objeto dinámicamente, proporcionando una alternativa flexible a la herencia para extender la funcionalidad
Pros
Mas flexibilidad que la herencia multiple estatica Evita clases cargadas con funciones en la parte de arriba de la jerarquía
Cons
Un decorador y su componente no son idénticos Aparecen muchos objetos pequeños
Proposito
Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna
Pros
Permite variaciones en el recorrido de un agregado Simplifica la interfaz del objeto agregado Se puede hacer mas de un recorrido a la vez sobre un agregado
Proposito
Proporciona un representante o sustituto de otro objeto para controlar el acceso a éste
Pros
Remoto: oculta el hecho de residir en un espacio de direcciones diferente Virtual: puede llevar a cabo optimizaciones tales como crear objetos por encargo Proteccion: permite realizar tareas adicionales cuando se accede a un objeto Copia de escritura: copia a los clientes que quiera modificarlo
Proposito
Define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que los usan
Pros
Permite familias de algoritmos relacionados Alternativo a la herencia Las estrategias eliminan las sentencias condicionales Permite eleccion de implementaciones
Cons
Costes de comunicacion Mayor numero de objetos