1 / 82

ISD. Curso 2003/04

ISD. Curso 2003/04. Módulo 3: Diseño orientado a objetos. Contenidos. Heurísticas de diseño orientado a objetos. noción de heurística clasificación catálogo de heurísticas Patrones de diseño. noción de patrón de diseño clasificación catálogo de patrones Refactorización.

brady-logan
Download Presentation

ISD. Curso 2003/04

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ISD. Curso 2003/04 Módulo 3:Diseño orientado a objetos

  2. Contenidos • Heurísticas de diseño orientado a objetos. • noción de heurística • clasificación • catálogo de heurísticas • Patrones de diseño. • noción de patrón de diseño • clasificación • catálogo de patrones • Refactorización. • noción de refactorización • situaciones susceptibles de refactorización • catálogo de refactorizaciones

  3. Parte I. Heurísticas de diseño • Recomendaciones para obtener un diseño orientado a objetos adecuado: • eliminando la complejidad accidental, • favoreciendo la reutilización, • facilitando el mantenimiento, • mejorando el paso a la implementación. • No siempre es posible aplicarlas. Bibliografía: A. J. Riel, Object-Oriented Design Heuristics, Addison Wesley, 1996

  4. Heurísticas de diseño. Clasificación • Los bloques básicos: clases y objetos • independencia modular, cohesión y acoplamiento. • Topología de las aplicaciones • orientadas a objetos vs. orientadas a acciones • Relaciones entre objetos • composición, agregación, asociación... • La herencia • ... y la herencia múltiple • Otras heurísticas de diseño

  5. Punto Punto Punto abscisa() x + x, y: float - x, y: float - rho, theta: float + trasladar(float, float) + distancia(Punto) + abscisa() : float + ordenada(): float + trasladar(float, float) + distancia(Punto) : float + abscisa() : float + ordenada(): float + trasladar(float, float) + distancia(Punto) : float Los bloques básicos: clases y objetos (I) • Los atributos deben declararse ocultos. • el acceso debe realizarse a través de métodos, y sólo cuando sea necesario. - Se evita la dependencia de los clientes. - Se facilita el mantenimiento.

  6. AlarmClock alarm_off Person -alarm : time TimeClockSafe alarm_on -alarm_status : boolean -age : int -money : int -now : time -name : String -openingTime : time +alarm_off() +alarm_on() Los bloques básicos: clases y objetos (II) • Los clientes de una clase deben depender de la interfaz pública de esta, pero una clase no debe depender de sus clientes. • debe aclararse la dirección de las asociaciones • un modelo no debe depender de la interfaz de usuario - Se facilita la reutilización.

  7. Los bloques básicos: clases y objetos (III) • El número de métodos de la interfaz de una clase debe ser reducido. • Si el tamaño de la interfaz es excesivo, se debe revisar el diseño, considerando la posibilidad de realizar una distribución de la clase en subclases. - Se facilita la comprensión y el uso de la clase.

  8. Los bloques básicos: clases y objetos (IV) • Las clases deben ofrecer una interfaz mínima que todos sus potenciales clientes comprendan: • construcción (manteniendo integridad) • copia (profunda vs. superficial) • igualdad (de objetos vs. de referencias) • representación (impresión) • serialización (transmisión, almacenamiento) • autocomprobación • etc.

  9. Los bloques básicos: clases y objetos (V) • Evitar incluir en la interfaz pública de una clase detalles de implementación. • métodos auxiliares privados. • métodos que deberían figurar protegidos. • Las clases sólo deberían utilizar detalles públicos del comportamiento de otras clases. • no abusar de mecanismos de exportación selectiva • “friend” de C++. • paquetes de Java. - Disminuye el acoplamiento.

  10. Los bloques básicos: clases y objetos (VI) • Una clase debe reflejar la abstracción de una única entidad dentro del modelo del dominio. • si una clase represente varias entidades, estamos creando un sistema excesivamente centralizado • la clase debe partirse en varias, o bien • la clase debe subclasificarse de forma adecuada. • si una entidad esta representada por varias clases, éstas corresponden probablemente a funciones. • las funciones deben agruparse en una clase.

  11. Los bloques básicos: clases y objetos (y VII) • Los datos y comportamiento relacionados deben mantenerse en una misma clase. • evitar implementar fuera de una clase comportamiento que le corresponde a ella. • Una clase no debe incluir información disjunta (comportamiento asilado). • será necesario dividir la clase en varias. • Vigilar que las abstracciones que modelan varias clases no se correspondan simple-mente con roles que juegan los objetos. • el criterio ha de ser que el comportamiento sea distinto. • un objeto puede utilizar sólo un subconjunto de su comportamiento.

  12. Topología de las aplicaciones (I) • Aplicaciones orientadas a acciones: • Descomposición funcional • Control centralizado • Aplicaciones orientadas a objetos: • Descomposición de datos • y sus funciones asociadas • Control descentralizado El desarrollo orientado a objetos permite abordar mejor la complejidad esencial, pero implica un cambio de paradigma y un proceso de aprendizaje.

  13. Topología de las aplicaciones (II) • No deben crearse clases/objetos excesiva-mente protagonistas (God classes). • Clases como Controller,Manager,System suelen resultar peligrosas. • a menudo estas clases manejan información disjunta • Vigilar las clases con muchas funciones de acceso (get/set). • los datos y el comportamiento relacionados deben figurar en la misma clase. • Es conveniente distribuir la inteligencia del sistema de la forma más uniforme posible.

  14. Topología de las aplicaciones (III) • Modelar el mundo real siempre que sea posible. Esta heurística es a menudo incompatible con: • distribuir la inteligencia del sistema • no definir clases “protagonistas” • mantener datos y comportamiento asociado en una misma clase. • Favorece la comprensión del sistema y el mantenimiento.

  15. Topología de las aplicaciones (y IV) • Eliminar clases irrelevantes • clases que son externas al sistema, • clases que sólo incluyen métodos como “get”, “set” pueden ser sustituidas por atributos en otras clases. • No considerar acciones como clases • clases con nombres que son verbos o derivados, • clases con una única acción. • Determinar qué “actores” del análisis deben mantenerse en el diseño: • eliminar las clases que modelan agentes irrelevantes para el diseño.

  16. Relaciones entre objetos (I) Grados de la relación de uso entre objetos: • Composición • un objeto contiene una instancia de la clase usada • Agregación • un objeto contiene una referencia al objeto que usa • Acceso global • todos los objetos conocen al objeto usado • Acceso temporal • la referencia al objeto usado se obtiene como parámetro • Creación local • un objeto crea localmente otro para usarlo

  17. Relaciones entre objetos (II) • Una clase no debe contener más objetos de los que se puedan recordar. • algunos estudios fijan el máximo en seis. • Minimizar el número de clases con las que se colabora. • se puede conseguir usando clases contenedoras. • Minimizar el número de mensajes intercambiados. • tanto correspondientes a la misma operación, • como a operaciones distintas.

  18. Relaciones entre objetos (y III) • Si una clase contiene objetos de otras, debería enviar mensajes a estos objetos. • la contención debe implicar una relación de uso. • Los objetos que comparten ámbito no deben tener relaciones de uso entre ellos. • la relación se debe establecer a través del continente. • Un objeto debe saber qué objetos contiene, pero no quién lo contiene a él. • la relación de contención es unidireccional.

  19. La herencia (I) • La herencia debe usarse para modelar la especialización. • debe evitarse la herencia de implementación. • Es beneficioso potenciar la profundidad en la jerarquía de herencia • Las características comunes deben identificarse lo más alto posible. • si varias clases comparten estado y comportamiento, estos se incluirán en una clase, de la que aquéllas heredarán. • Si varias clases comparten sólo datos, estos deben definirse en una clase aparte, • contenida (no heredada) en cada una de ellas.

  20. La herencia (II) • Las clases derivadas pueden conocer sus clases base. • pero no al revés. • Toda clase abstracta debe tener clases herederas. • la raíz de una jerarquía de herencia suele ser abstracta. • No confundir instancias de una clase con clases derivadas. • No es habitual necesitar crear clases en tiempo de ejecución. • lo que se deben crear son objetos.

  21. La herencia (III) • Evitar hacer análisis de casos explícito sobre el tipo de un objeto. • se debe utilizar para ello el polimorfismo. • El análisis de casos sobre el valor de un atributo constituye a menudo un error. • se puede aplicar el patrón Estado.

  22. La herencia (y IV) • No se debe confundir una relación de contención opcional con la necesidad de heredar. • esto suele derivar en una proliferación de clases. • el patrón Decorador suele ser una solución. • Cuando se construya una jerarquía de herencia, se debe construir marcos reutilizables, en vez de componentes reutilizables. • esta es la idea detrás de los patrones de diseño.

  23. ... y la herencia múltiple • La herencia múltiple es bastante inusual. • debemos asegurarnos de que ninguna de las superclases es heredera de otra. • evitar utilizar herencia cuando en realidad se está modelando una relación de composición. • Incluso cuando forme parte del modelo en el análisis, puede ser conveniente evitar la herencia múltiple en el diseño. • combinando herencia simple y composición. • utilizando implementación múltiple de interfaces.

  24. Otras heurísticas de diseño • Siempre que sea posible decidir entre una relación de agregación y otra de asociación, es mejor optar por la primera. • No se deben utilizar datos o funciones globales para mantener información entre los objetos de una clase. • este es el objetivo de los métodos y variables de clase. • Un diseñador no debe atender a cuestiones como el lenguaje de implementación, características físicas de las plataformas donde se va a implantar el sistema, y otras similares, si esto supone una corrupción del diseño lógico del sistema.

  25. Parte II. Patrones de diseño • La noción de patrón de diseño. • Ventajas e inconvenientes. • Clasificación de patrones de diseño. • Ejemplos. Bibliografía: E. Gamma et al., Design Patterns, Addison Wesley, 1995

  26. Patrones de diseño • Los L.O.O. facilitan la reutilización de código • pero un buen diseño es la clave para una reutilización efectiva. • Un diseñador experimentado producirá diseños más simples, robustos y generales • y más fácilmente adaptables a cambios. • Los patrones de diseño pretenden transmitir esa experiencia: • son soluciones efectivas a problemas comunes.

  27. La noción de patrón • Un patrón es una solución probada • aplicable a un determinado tipo de problemas • que aparecen repetidamente en el desarrollo de software. • No son bibliotecas de clases • sino un “esqueleto” básico • que se debe adaptar a las peculiaridades de la aplicación. • Los patrones se describen en forma textual • acompañados de diagramas y pseudocódigo. • Dos niveles: • patrones de diseño y de arquitectura.

  28. Patrones de arquitectura • Son esquemas de organización de un sistema. • Especifican una serie de subsistemas • y sus responsabilidades respectivas. • Incluyen reglas para organizar las relaciones entre ellos. • Ejemplos: • niveles • particiones • filtros y tuberías • cliente-servidor

  29. Patrones de arquitectura: ejemplo

  30. Interfaz de usuario Constr. expresiones Ficheros Análisis semántico Ejecut. Op. Sustituir Racionalizar Evaluar Guardar Cargar Análisis semántico Patrones de arquitectura: ejemplo INTÉRPRETE DE COMANDOS SISTEMA OPERATIVO

  31. Patrones de diseño • Tienen un nivel de abstracción menor. • Están más próximos a la implementación final. • Su uso no se refleja en la estructura global del sistema. • Ejemplos: • Adaptador • Estado • Singular • Iterador • Decorador

  32. Ventajas de los patrones de diseño (I) • Son soluciones concretas: • un catálogo de patrones es un conjunto de recetas de diseño. • cada patrón es independiente del resto. • Son soluciones técnicas: • dada una situación, los patrones indican cómo resolverla. • existen patrones específicos para un lenguaje determinado. • Se aplican en situaciones muy comunes: • proceden de la experiencia. • han demostrado su utilidad.

  33. Ventajas de los patrones de diseño (II) • Son soluciones simples: • indican cómo resolver un problema utilizando un pequeño número de clases relacionadas de forma determinada. • no indican cómo diseñar un sistema completo, sino sólo aspectos puntuales del mismo. • Facilitan la reutilización del código y del diseño: • los patrones favorecen la reutilización de clases ya existentes y la programación de clases reutilizables. • la propia estructura del patrón se reutiliza cada vez que se aplica.

  34. Inconvenientes de los patrones de diseño • Su uso no se refleja claramente en el código: • a partir de la implementación es difícil determinar qué patrón de diseño se ha utilizado. • no es posible hacer ingeniería inversa. • Referencias a “this”: • a menudo los mensajes se resuelven mediante delegación. • Es difícil reutilizar la implementación del patrón: • el patrón describe roles genéricos, pero en la implementación aparecen clases y métodos concretos. • Suponen cierta sobrecarga: • se usan más clases de las estrictamente necesarias. • la delegación implica un nivel de indirección más.

  35. MVC: Un ejemplo de patrón de diseño • En Smalltalk-80 se utiliza una relación entre clases denominada MVC (Modelo/Vista/Control), que se repite en otras muchas situaciones. • MVC se puede considerar como un ejemplo típico de patrón de diseño. • Se utiliza para construir interfaces de usuario distinguiendo tres tipos de objetos: • El modelo es el objeto que se desea evaluar. • La vista (o vistas) dan la información visual del objeto y permiten el acceso al mismo mediante una interfaz de usuario. • El controlador se encarga de atender las peticiones que el usuario realiza sobre la vista, invocando las acciones necesarias sobre el modelo.

  36. Modelo-Vista-Controlador • Podemos disponer de: • Un modelo. • Varias vistas. • Varios controladores. • Vistas y Controladores están muy relacionados. • A veces puede disponerse de varias vistas para el mismo controlador.

  37. La clase Cambio • Posteriormente la utilizaremos como modelo. • Permite realizar cambios de euros a pesetas. • El constructor decide el cambio de euros a pesetas. • Métodos para: • Pasar una cantidad de pesetas a euros. • Conocer los euros que han resultado. • Pasar una cantidad de monedas a pesetas. • Conocer las pesetas que han resultado. • Hay métodos para conocer: • Moneda origen, moneda destino, cantidad origen y cantidad destino.

  38. La clase Cambio public class Cambio { final static public String EUROS = "euros"; final static public String PESETAS = "pesetas"; float factor; String monedaF; float valorF; float valorI; public Cambio(float fac) { monedaF = EUROS; factor = fac; // de paso de ptas a euros } public void aPesetas(float cantidad) { public float valorF(){ monedaF = PESETAS; return valorF; valorI = cantidad; } valorF = cantidad * factor; public float valorI(){ } return valorI; public void aEuros(float cantidad) { } monedaF = EUROS; public String monedaF(){ valorI = cantidad; return monedaF; valorF = cantidad / factor; } } public String monedaI() { return (monedaF.equals(EUROS)?PESETAS:EUROS); } }

  39. Test para la clase Cambio public class TestCambioConsola { static public void main(String args []) { Cambio cpe = new Cambio(166.386f); System.out.println("Comienza"); System.out.println ("Le damos 4578 pesetas"); cpe.aEuros(4578); System.out.println ("Y devuelve "+ cpe.valorF()+" " + cpe.monedaF()); System.out.println ("Le damos 35.67 euros"); cpe.aPesetas(35.67f); System.out.println ("Y devuelve "+ cpe.valorF()+" " + cpe.monedaF()); } } Comienza Le damos 4578 pesetas Y devuelve 27.514334 euros Le damos 35.67 euros Y devuelve 5934.9883 pesetas

  40. Ejemplo: Modelo-Vista-Controlador Cambio Controlador Vistas CtrCambio Modelo

  41. Vistas: Vista1 y Vista2 • Interfaz para las vistas: public interface VistaCambio { void limpiar(); float valorEntrada(); void agregaLinea(String s); void controlador(CtrCambio crt); } • El método controlador(CtrCambio ctrl) • Pone al controlador ctrl como oyente de los componentes adecuados. • Creamos dos vistas distintas sobre el mismo controlador • Vista1 y Vista2

  42. Controlador: CrtCambio • Mantiene dos variables de instancia: • El modelo: cpe • La vista : vc public CrtCambio(VistaCambio v, Cambio c ) { vc = v; // La vista cpe = c; // El modelo }

  43. Aplicación import javax.swing.*; public class TestCambio { public static void main(String args[]) { System.out.println("Starting Cambio..."); VistaCambio vis = new Vista1(); // Vista2() Cambio mod = new Cambio(166.386f); CrtCambio crt = new CtrCambio(vis,mod); vis.controlador(crt); ((JFrame)vis).pack(); ((JFrame)vis).setTitle("Ejemplo Cambio"); ((JFrame)vis).setVisible(true); } }

  44. Clasificación de los patrones de diseño • Según su propósito: • Patrones de creación. • problemas de creación de instancias. • Patrones estructurales. • problemas de relaciones entre clases y/u objetos. • Patrones de comportamiento. • forma en que los objetos interactúan y distribuyen sus responsabilidades. • Según su ámbito: • Patrones de clases. • se resuelven mediante relaciones de herencia entre clases. • Patrones de objetos. • se resuelven mediante relaciones de uso entre objetos.

  45. Catálogo de Gamma et al. (1995)

  46. Adaptador • Adapta la interfaz de una clase a la interfaz esperada por sus clientes. • Favorece la reutilización (de la clase adaptada) y permite la colaboración con interfaces incompatibles. • También se conoce como Wrapper. • Es un patrón estructural con una versión para clases y otra para objetos.

  47. Adaptador: motivación • Se está desarrollando un editor de dibujos que permite realizar diagramas a partir de elementos gráficos como líneas, círculos, texto, etc. • Un elemento fundamental de dicho sistema es la clase ObjetoGráfico, que proporciona operaciones para modificar su forma (editar()) y para representarlo (dibujar()). • Esta clase se especializa para cada tipo de objeto gráfico:Línea, Círculo, etc., clases donde se han implementado adecuadamente dichas operaciones. • Sin embargo, la edición y representación de textos es una tarea complicada, por lo que se desea reutilizar la claseText de la biblioteca de clases del entorno de programación. • No obstante, la interfaz deText(con operaciones comoedit()ydraw()) no se corresponde con la declarada porObjetoGráfico. • Por este motivo, se necesita desarrollar una claseTexto(adaptador) que adapte la claseText(adaptada) a la interfaz declarada porObjetoGráfico(objetivo).

  48. Adaptador: motivación ObjetoGráfico Text dibujar( ) draw( ) editar( ) edit( ) Línea Círculo dibujar( ) dibujar( ) editar( ) editar( )

  49. ObjetoGráfico Text dibujar( ) draw( ) editar( ) edit( ) text Línea Círculo Texto dibujar( ) dibujar( ) dibujar( ) editar( ) editar( ) editar( ) dibujar( ) { text.draw( ); } editar( ) { text.edit( ); } Adaptador: versión para instancias

  50. ObjetoGráfico Text dibujar( ) draw( ) editar( ) edit( ) Línea Círculo Texto dibujar( ) dibujar( ) dibujar( ) editar( ) editar( ) editar( ) dibujar( ) { draw( ); } editar( ) { edit( ); } Adaptador: versión para clases

More Related