Patrones De DiseñO

2,325 views

Published on

Trabajo patrones de diseño
Ingenieria de Software I
Universidad Distrital Fancisco Jose de Caldas

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,325
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
116
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Patrones De DiseñO

  1. 1. Erika E. Abreo Rojas cod 20041020034 Wilmer D. Galvis Monroy cod 20041020023 Ronald F. Rodriguez cod.20032020120
  2. 3. Patrones estructurales <ul><li>El interés de los patrones estructurales, esta en conocer como se clasifica y como se componen los objetos para formar estructuras mas grandes. </li></ul><ul><li>Estos patrones usan herencia para componer interface o aplicaciones. Un ejemplo simple es la herencia múltiple, el como mescla dos o mas clases en una sola. </li></ul><ul><li>Patrones estructurales: </li></ul><ul><ul><li>Object Adapter </li></ul></ul><ul><ul><li>Bridge </li></ul></ul><ul><ul><li>Composite </li></ul></ul><ul><ul><li>Decorator </li></ul></ul><ul><ul><li>Facade </li></ul></ul><ul><ul><li>Flyweight </li></ul></ul><ul><ul><li>Proxy </li></ul></ul>
  3. 4. FACHADA <ul><li>Propósito </li></ul><ul><ul><li>Proporcionar una interfaz unificada para un conjunto de interfaces en un subsistema, haciéndolo más fácil de usar, simplificando el acceso a un conjunto de objetos proporcionando uno que todos los clientes pueden usar para comunicarse con el conjunto. </li></ul></ul><ul><li>Motivación </li></ul><ul><ul><li>Minimizar las comunicaciones y dependencias entre subsistemas </li></ul></ul><ul><ul><li>El sistema usuario no necesita saber en la mayoría de los casos nada sobre el transporte </li></ul></ul><ul><ul><li>Fachada al subsistema de comunicaciones = Sockets </li></ul></ul>
  4. 5. FACHADA ( Estructura )
  5. 6. <ul><li>Los clientes se comunican con el subsistema haciendo peticiones a la Fachada, que las envía a los objetos del subsistema apropiados (la fachada podría también traducir su interfaz a la de las interfaces del subsistema) </li></ul><ul><li>Los clientes que usan la fachada no tienen que acceder a los objetos del subsistema directamente </li></ul>FACHADA ( Participantes ) Conoce los objetos del subsistema responsables para cada petición, y Conoce los objetos del subsistema responsables para cada petición, y delega en ellos las peticiones de los clientes. Implementan la funcionalidad del subsistema. No tienen conocimiento de la fachada
  6. 7. <ul><ul><li>Facade </li></ul></ul><ul><ul><ul><li>Sabe qué clases del subsistema son las responsables ante una petición </li></ul></ul></ul><ul><ul><ul><li>Delega las peticiones de los clientes en los objetos apropiados del subsistema. </li></ul></ul></ul><ul><ul><li>Subsistem Classes </li></ul></ul><ul><ul><ul><li>Implementan la funcionalidad del subsistema. </li></ul></ul></ul><ul><ul><ul><li>Realizan las labores encomendadas por el objeto Fachada. </li></ul></ul></ul><ul><ul><ul><li>No conocen a la fachada, es decir, no tienen referencias a ella. </li></ul></ul></ul>FACHADA ( Participantes )
  7. 8. <ul><li>Para proporcionar una interfaz sencilla a un subsistema complejo </li></ul><ul><ul><li>A medida que un subsistema evoluciona va teniendo más clases,más pequeñas, más flexibles y configurables </li></ul></ul><ul><ul><li>Hay clientes que no necesitan tanta flexibilidad y que quieren una visión más simple del subsistema </li></ul></ul><ul><ul><li>Sólo los clientes que necesiten detalles de más bajo nivel accederán a las clases detrás de la fachada </li></ul></ul><ul><li>Cuando hay muchas dependencias entre los clientes y las clases de implementación de una abstracción </li></ul><ul><ul><li>La fachada desacopla el subsistema de los clientes y de otros subsistemas </li></ul></ul><ul><ul><li>Esto mejora la independencia de subsistemas y la portabilidad </li></ul></ul>FACHADA (Aplicabilidad)
  8. 9. <ul><li>Para estructurar un sistema en capas </li></ul><ul><ul><li>La fachada define el punto de entrada de cada nivel </li></ul></ul><ul><ul><li>Se pueden simplificar las dependencias obligando a los subsistemas a comunicarse únicamente a través de sus fachadas </li></ul></ul>FACHADA (Aplicabilidad)
  9. 10. <ul><li>Oculta a los clientes los componentes del subsistema </li></ul><ul><li>Reduce el número de objetos con los que tienen que tratar los clientes </li></ul><ul><li>Disminuye el acoplamiento entre un subsistema y sus clientes </li></ul><ul><li>Un menor acoplamiento facilita el cambio de los componentes del subsistema sin afectar a sus clientes </li></ul><ul><li>Las fachadas permiten estructurar el sistema en capas </li></ul><ul><li>Reduce las dependencias de compilación </li></ul><ul><li>No evita que las aplicaciones puedan usar las clases del subsistema si lo necesitan </li></ul><ul><li>Se puede elegir entre facilidad de uso y generalidad </li></ul>FACHADA (Consecuencias)
  10. 11. <ul><ul><li>Abstract Factory </li></ul></ul><ul><ul><ul><li>Puede usarse para proporcionar una interfaz para crear el subsistema de objetos. </li></ul></ul></ul><ul><ul><li>Mediator </li></ul></ul><ul><ul><ul><li>Parecido al Facade en que abstrae la funcionalidad a partir de unas clases existentes, la diferencia es que el Mediator también se encarga de la comunicación entre objetos. </li></ul></ul></ul><ul><ul><li>Singleton. </li></ul></ul><ul><ul><ul><li>Normalmente solo se necesita un objeto fachada por lo que estos se suelen implementar como Singleton. </li></ul></ul></ul>FACHADA ( Patrones relacionados )
  11. 13. Patrones de comportamiento <ul><ul><li>Se preocupan por la asignación de responsabilidades entre objetos. Los patrones de comportamiento no solo describen el uso de estos en los objetos y/o clases, además los patrones de comunicación entre ellos. </li></ul></ul><ul><ul><li>Se utilizan para organizar,manejar y combinar comportamientos. </li></ul></ul>
  12. 14. Patrones de comportamiento <ul><li>Tipos de patrones de Comportamiento: </li></ul><ul><ul><ul><li>Chain of Responsability </li></ul></ul></ul><ul><ul><ul><li>Command </li></ul></ul></ul><ul><ul><ul><li>Interpreter </li></ul></ul></ul><ul><ul><ul><li>Iterator </li></ul></ul></ul><ul><ul><ul><li>Mediator </li></ul></ul></ul><ul><ul><ul><li>Memento </li></ul></ul></ul><ul><ul><ul><li>Observer </li></ul></ul></ul><ul><ul><ul><li>State </li></ul></ul></ul><ul><ul><ul><li>Strategy </li></ul></ul></ul><ul><ul><ul><li>Template Method </li></ul></ul></ul><ul><ul><ul><li>Visitor </li></ul></ul></ul>
  13. 15. COMANDO <ul><li>Conocido como … </li></ul><ul><ul><li>Command, Comando. </li></ul></ul><ul><li>Motivación </li></ul><ul><ul><ul><li>Necesidad de enviar peticiones a objetos sin conocer nada sobre la operación solicitada o su receptor. </li></ul></ul></ul><ul><ul><ul><li>Por ejemplo menús o botones en toolkits de IU. </li></ul></ul></ul><ul><ul><ul><li>El usuario decide quien maneja la petición, </li></ul></ul></ul><ul><ul><ul><li>La propia petición interesa que sea un objeto. </li></ul></ul></ul>
  14. 16. COMANDO( Estructura )
  15. 17. COMANDO( Estructura )
  16. 18. COMANDO( Participantes ) <ul><ul><li>AbstractCommand. </li></ul></ul><ul><ul><ul><li>Clase que ofrece un interfaz para la ejecución de comandos. Define los métodos do y undo que se implementarán en cada clase concreta. ConcreteCommand. Clase que implementa un comando concreto y sus métodos do y undo. Su constructor debe inicializar los parámetros del comando. </li></ul></ul></ul><ul><ul><li>Invoker. </li></ul></ul><ul><ul><ul><li>Clase que instancia los comandos, puede a su vez ejecutarlos inmediatamente (llamando a do) o dejar que el CommandManager lo haga. </li></ul></ul></ul>
  17. 19. COMANDO( Participantes ) <ul><ul><li>CommandManager. </li></ul></ul><ul><ul><ul><li>Responsable de gestionar una colección de objetos comando creadas por el Invoker. llamará a los métodos doIt y unDoIt. Gestionará su secuenciación y reordenación (en base a prioridades por ejemplo). </li></ul></ul></ul><ul><ul><li>Receiver (Calculator) </li></ul></ul><ul><ul><ul><li>Sabe cómo llevar a cabo las operaciones asociadas a una petición. Cualquier clase puede actuar como receptor. </li></ul></ul></ul>
  18. 20. COMANDO(Aplicabilidad) <ul><ul><ul><li>Parametrizar objetos con una acción a realizar </li></ul></ul></ul><ul><ul><ul><li>Especificar, poner en cola y ejecutar peticiones diferentes en diferentes instantes. </li></ul></ul></ul><ul><ul><ul><li>Permitir deshacer las acciones, la propia orden puede guardar el estado que anula sus efectos. </li></ul></ul></ul><ul><ul><ul><li>Permitir registrar los cambios de manera que se puedan aplicar de nuevo en caso de una caída del sistema (transacciones). </li></ul></ul></ul>
  19. 21. COMANDO(Consecuencias) <ul><ul><li>Se independiza la parte de la aplicación que invoca los comandos de la implementación de los mismos. </li></ul></ul><ul><ul><li>Al tratarse los comandos como objetos, se puede realizar herencia de los mismos, composiciones de comandos (mediante el patrón Composite). </li></ul></ul><ul><ul><li>Se facilita la ampliación del conjunto de comandos. </li></ul></ul>
  20. 22. COMANDO( Patrones relacionados ) <ul><ul><li>Template Method </li></ul></ul><ul><ul><ul><li>Puede servir para implementar la lógica de Deshacer de forma un tanto automática o a alto nivel. </li></ul></ul></ul><ul><ul><li>Composite </li></ul></ul><ul><ul><ul><li>Permite realizar agrupaciones de comandos de forma similar a una macro. </li></ul></ul></ul><ul><ul><li>Prototype </li></ul></ul><ul><ul><ul><li>Hay quien lo utiliza para implementar la copia del comando al histórico de comandos. </li></ul></ul></ul>
  21. 23. COMANDO( Ejemplo ) <ul><li>public interface Command{ </li></ul><ul><li>void execute(); </li></ul><ul><li>} </li></ul><ul><li>public class CommandGenerarNominas implements Command{ </li></ul><ul><li>Universidad _universidad; </li></ul><ul><li>public CommandGenerarNominas(Universidad universidad){ </li></ul><ul><li>_universidad = universidad; </li></ul><ul><li>} </li></ul><ul><li>public void execute(){ </li></ul><ul><li>_universidad.generarNominas(); </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  22. 24. COMANDO( Ejemplo ) <ul><li>public class MenuUniversidad { </li></ul><ul><li>public boolean menuPrincipal(){ </li></ul><ul><li>... </li></ul><ul><li>case 3: // generar nominas </li></ul><ul><li>// _universidad.generarNominas(); </li></ul><ul><li>Command comando; </li></ul><ul><li>comando = new CommandGenerarNominas(_universidad); </li></ul><ul><li>comando.execute(); </li></ul><ul><li>break ; </li></ul><ul><li>... </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  23. 25. OBSERVER
  24. 26. OBSERVER <ul><li>Conocido como … </li></ul><ul><ul><li>Este patrón (algunas veces conocido como editor/subscriptor) es un patrón de diseño usado en programación para observar el estado de un objeto en un programa. Está relacionado con el principio de invocación implícita. </li></ul></ul><ul><li>Motivación </li></ul><ul><ul><ul><li>DOO = Dividir sistemas en clases cooperantes </li></ul></ul></ul><ul><ul><ul><li>Necesitamos mantener la consistencia entre los estados de esas clases </li></ul></ul></ul><ul><ul><ul><li>Evitar proveer esa consistencia a base de acoplamiento </li></ul></ul></ul><ul><ul><ul><li>El acoplamiento reduce la reutilización </li></ul></ul></ul>
  25. 27. OBSERVER ( Estructura )
  26. 28. OBSERVER ( Participantes ) <ul><ul><li>Subject </li></ul></ul><ul><ul><ul><ul><li>Conoce a sus observadores. Un sujeto puede ser observado por cualquier número de objetos Observador. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Proporciona una interfaz para asignar y quitar objetos Observador. </li></ul></ul></ul></ul><ul><ul><li>ConcreteSubject </li></ul></ul><ul><ul><ul><ul><li>Almacena el estado de interés para los objetos observador concretos. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Envía una notificación a sus observadores cuando cambia su estado . </li></ul></ul></ul></ul>
  27. 29. OBSERVER ( Participantes ) <ul><ul><li>Observer </li></ul></ul><ul><ul><ul><ul><li>Define una interfaz para actualizar los objetos que deben ser notificados ante cambios en un sujeto. </li></ul></ul></ul></ul><ul><ul><li>ConcreteObserver </li></ul></ul><ul><ul><ul><ul><li>Mantiene una referencia a un objeto sujeto concreto. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Guarda un estado que debería ser consistente con el sujeto. Implementa la interfaz de actualización del observador para mantener su estado consistente con el del sujeto. </li></ul></ul></ul></ul>
  28. 30. OBSERVER(Aplicabilidad) <ul><ul><ul><li>Cuando una abstracción tiene dos aspectos dependientes entre si. Encapsular estos aspectos como objetos separado incrementa la reutilización. </li></ul></ul></ul><ul><ul><ul><li>Cuando un cambio en un objeto exige la actualización de un número desconocido de objetos relacionados. </li></ul></ul></ul><ul><ul><ul><li>Cuando un objeto debe ser capaz de notificar a otros sin tener que saber quienes son esos objetos. No queremos acoplar esos objetos. </li></ul></ul></ul>
  29. 31. OBSERVER(Consecuencias) <ul><li>Ventajas: </li></ul><ul><ul><li>Permite modificar las clases subjects y las observers independientemente. Se pueden rehusar clases subjects sin rehusar sus clases observers. </li></ul></ul><ul><ul><li>Permite añadir nuevas clases observers a una clase subject que ya tenía asociadas unas clases observers sin modificar la clase subject o alguno de esas clases observers que ya tenía. </li></ul></ul><ul><ul><li>Permite que dos capas de abstracción de diferentes niveles de abstracción se puedan comunicar entre sí sin romper esa división en capas de abstracción. Por ejemplo, en el caso de las capas de Presentación y Dominio. </li></ul></ul>
  30. 32. OBSERVER(Consecuencias) <ul><li>Desventajas: </li></ul><ul><ul><li>Aumenta el número de clases necesarias para implementar la aplicación y disminuye la comprensibilidad de ésta. </li></ul></ul><ul><ul><li>Los observers dependen del subject al que observan, pues lo conocen (hacen referencia a él), por lo que cambios en la clase del subject pueden provocar cambios en las de los observers . </li></ul></ul>
  31. 33. OBSERVER( Patrones relacionados ) <ul><ul><li>Mediator </li></ul></ul><ul><ul><ul><li>S e puede utiliza para encapsular la lógica de actualización si esta es compleja, en un gestor de cambios que evite acoplar sujetos y observadores. </li></ul></ul></ul>
  32. 34. OBSERVER( Ejemplo ) public abstract class Subject { private List<Observer> observers; public void add(Observer o) { this .observers.add(o); } public void remove(Observer o) { this .observers.remove(o); } public void notify() { for ( int i = 0; i< this .observers.size(); i++) this .observers.get(i).update(); } public Subject() { this .observers = new ArrayList<Observer>(); } } public abstract class Observer { private Subject subject; protected Subject getSubejct() { return this.subject; } public Observer(Subject s) { this.subject = s; } public abstract void update(); }
  33. 35. OBSERVER( Ejemplo ) public class Dominio extends Subject { private double a , b , c ; public Dominio( double [3] s) { super (); this .a = s[0]; this .b = s[1]; this .c= s[2]; } public double [3] getState() { double [3] s = new double [3]; s[0] = this .a; s[1] = this .b; s[2] = this .c; return s; } public void setState( double [3] s) { this .a = s[0]; this .b = s[1]; this .c= s[2]; this .notify(); } } public class Vista1 extends Observer { private double [][] tabla = new double [3][3]; private int sig = 0; public Vista1(Dominio d) { super (d); this .update(); } public void update() { double [3] s = ((Dominio).getSubject()).getState(); this .tabla[sig] = s; sig = (sig+1)%3; this .redibujar(); } }
  34. 36. OBSERVER( Ejemplo ) public class Vista2 extends Observer { private double a , b , c ; public Vista2(Dominio d) { super (d); this .update(); } public void update() { double [3] s = ((Dominio)getSubject()).getState(); a = s[0]; b = s[1]; c = s[2]; this .redibujar(); } } public class Vista3 extends Observer { private double a , b , c ; public Vista3(Dominio d) { super (d); this .update(); } public void update() { double [3] s = ((Dominio)getSubject()).getState(); a = s[0]; b = s[1]; c = s[2]; this .redibujar(); } }
  35. 37. BIBLIOGRAFIA <ul><li>GAMMA, Erick. HELM, Richard. JOHNSON, Ralph. VLISSIDES, John. Desing Patterns. Addison Wesley. 1998. </li></ul><ul><li>ARRIZABALAGA, Alvaro. Patrones y Software. Universidad de Deusto, Facultad de Ingenieria. Avan Group. </li></ul><ul><li>ESCALONA, David. Patrones de diseño. </li></ul>

×