| Revisión actual |
Tu texto |
| Línea 27: |
Línea 27: |
| '''''Intent''''' | | '''''Intent''''' |
|
| |
|
| Proporciona una interfaz unificada para un conjunto de interfaces de subsistemas. Define una interfaz de alto nivel que hace que los subsistemas sean más fáciles de usar. | | 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. |
|
| |
|
| '''''Resumen''''' | | '''''Resumen''''' |
| Línea 42: |
Línea 42: |
|
| |
|
| == Composite == | | == Composite == |
|
| |
| '''''Intent'''''
| |
|
| |
| 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.
| |
|
| |
| '''''Resumen'''''
| |
|
| |
| La clave del patrón Compsite es una clase abstracta que representa tanto a primitivas como a sus contenedoras. De esta manera se representan estructuras arboreas, con elementos primitivos, de cualquier granularidad y para el cliente es transparente si esta trabajando con elementos primitivos o contenedores. Es uno de los patrones mas usado.
| |
|
| |
| '''''Consecuencias'''''
| |
|
| |
| Donde el código esepre un objeto primitivo, también podrá recibir un objeto compuesto.
| |
|
| |
| Simplifica al cliente quienes no conocen si trabajan con hojas o con estructuras compuestas.
| |
|
| |
| Se pueden añadir nuevos componentes de manera muy simple.
| |
|
| |
| Puede llegar a ser demasiado general. Si necesitaramos ciertas restricciones sobre los componentes de cierto compuesto esto es demasiado complejo.
| |
|
| |
| '''''Implementación'''''
| |
|
| |
| Se pueden mantener referencias explicitas al padre para simplificar recorrido.
| |
|
| |
| Donde se pone el protocolo de manejo de hijos? En la clase abstracta y se genera un error cuando se llama el mensaje sobre un primitivo? o directamente en la subclase compuesto?
| |
|
| |
| Puede pasar que necesitemos cierto orden sobre los elementos del compuesto.
| |
|
| |
|
| == Observer == | | == Observer == |
|
| |
| '''''Intent'''''
| |
|
| |
| Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y se actualicen automáticamente todos los objetos que dependen de él.
| |
|
| |
| '''''Resumen'''''
| |
|
| |
| El ejemplo clásico es el del Model View Controller donde elementos de las distintas posibles vistas dependen de un mismo elemento de modelo. El patrón Observer describe cómo establecer estas relaciones. Los principales objetos de este patrón son el sujeto y los observadores. Un sujeto cambia su estado y notifica a los observadores quienes en respuesta consultarán al sujeto para sincronizar su estado con este.
| |
|
| |
| '''''Consecuencias'''''
| |
|
| |
| Los distintos sujetos y observadores estan bastante desacoplados y se pueden modificar independientemente.
| |
|
| |
| Se pueden añadir y quitar observadores en cualquier momento.
| |
|
| |
| Se puede armar cierto problema cuando hay muchos observadores y se reciben notificaciones de cambio constantemente que para algunos observadores son insignificantes.
| |
|
| |
| '''''Implementación'''''
| |
|
| |
| Una cuestión importante es quien dispara la actualización.
| |
|
| |
| Lo puede hacer el sujeto cuando cambia de estado. La ventaja es que es transparente para los clientes y la desventaja que una llamada que involucre mas de una operación puede causar varias actualizaciones consecutivas.
| |
| Si, en cambio, lo hacen los clientes la ventaja es que lo haran solo cuando se realizó una vez que se hicieron los cambios de estado juntos, pero los clientes tienen esa responsabilidad demasiado importante y esto puede ser causa de errores.
| |
|
| |
| Finalmente la dicotomia entre el push y el pull. Si el sujeto envía información importante acerca del cambio a sus observadores (push) o si los observadores deben pedir esa información. El push es menos reutilizable y el pull puede ser mas infeciente.
| |
