clase Graphics

1

• clase Graphics
• cargar una imagen desde fichero
• dibujar líneas en el panel de dibujo
• modo XOR
• Diseño de aplicaciones
• Modelo MVC (Modelo-Vista-Control)

2
Cargar una imagen en una aplicación

• Utilizamos un objeto Toolkit para leer ficheros
  GIF y JPEG
• Ejemplo
• Toolkit kit Toolkit.getDefaultToolkit()
• Image foto kit.getImage(fotos/dni.jpeg)
• La variable foto contiene una referencia a un
  objeto que encapsula la imagen JPEG.
• Para visualizarla en una zona gráfica (objeto de
  tipo Graphics) se utiliza el método drawImage
• Graphics g jPanelDibujo.getGraphics()
• g.drawImage(foto, x, y, null) //ImageObserver
  null
• //también puede dibujarse a escala
• g.drawImage(foto, x, y, ancho, alto, null)

3
clase MediaTracker

• Se necesita para cargar completamente una imagen
  antes de procesar cualquier otro código.
• El código necesario es
• Toolkit kit Toolkit.getDefaultToolkit()
• Image foto kit.getImage(fotos/dni.jpeg)
• MediaTracker tracker new MediaTracker(this)
• tracker.addImage(foto, 0) //0 identificador
• try
• tracker.waitForID(0)
• //o bien tracker.waitForAll()
• catch (InterruptedException e)

4
Primitivas de dibujo en Graphics

• Ejemplos
• void drawLine(x1, y1, x2, y2)
• Dibuja una línea desde el punto (x1,y1) del área
  de dibujo al punto (x2, y2)
• void drawRect (x, y, ancho, alto)
• Dibuja un rectángulo situando la esquina
  superior izquierda en el punto (x, y). Los lados
  miden xalto y xancho.

5
Borrar imágenes. Modo XOR

• En la clase Graphics
• public void setXORMode(Color c1)
• Dibujar dos veces la misma imagen implica que se
  restauren los pixels al color original.
• Ejemplo
• Graphics g jPanel.getGraphisc()
• g.setXORMode(Color.white)
• 1) Pintar dos veces la misma imagen en este
  panel supone que el panel se ponga de color
  blanco (el color original). El efecto es que se
  borra la imagen de la pantalla.
• 2) Se puede pintar una imagen encima de otra.

6
Dibujar en un panel

• Se necesita
• Definir una clase que herede de JPanel.
• redefinir el método paintComponet, este método se
  llama automáticamente siempre que sea necesario
  redibujarse.
• class VisualizadorPanel extends JPanel
• public void paintComponent(Graphics g)
• super.paintComponent(g)
• //Código necesario para dibujar

7
Desarrollo de aplicaciones OO

• 1) Análisis del problema ? MODELO de la
  aplicación
• 1.1 Encontrar los objetos relevantes del dominio
  Ej Libro,Autor, ..
• 1.2 Describir los objetos encontrados y
  clasificar
• a) atributos y operaciones relaciones
  clientela Ej autor-libro
• b) herencia Ej Revista - Publicación
• 1.3 Implementar las clases en un lenguaje
• 2) Diseño de la solución surgen nuevos objetos
  no relacionados con el dominio
• 2.1 Diseño de la interfaz de usuario (VISTA)
• 2.2 Establecer el CONTROL interacción del
  usuario con la vista
• 2.3 Implementar las clases del diseño

8
Desarrollo de aplicaciones en Java

• Implementar las clases del MODELO.
• Definir el aspecto gráfico (VISTA)
• Definir los eventos que van a ocurrir sobre cada
  uno de los elementos de las ventanas eventos
  del sistema.
• eventos generados por un actor externo
• Implementar las acciones asociadas a la
  ocurrencia de un evento sobre los botones de la
  vista (CONTROL).
• Quién debe ser el responsable de gestionar
• los eventos del sistema?

9
Ejemplo.

• Sea el modelo

Contacto nombreString telefonoString

• La agenda es un catálogo de contactos
• public class Agenda
• private LinkedList contactos

10
presiona botón
actionPerformed(ActionEvent)
Capa de Interfaz
JFrameAgenda
nuevoContacto(nombre, tfno)

• Coordina la solicitud desde la UI
• Puede ser una clase que represente
• al sistema software completo

Capa del Dominio
Controlador
???
11
Beneficios del Controlador Reutilización de la
lógica de la aplicación en futuras aplicaciones
porque no está ligada a la capa de interfaz.
actionPerformed(ActionEvent)
actionPerformed(ActionEvent)
Capa de Interfaz
JFrameAgenda
JDialogAlta
nuevoContacto(nombre,tfno)
Capa del Dominio
Controlador
12
Modelo de delegación de eventos

• Debemos definir los cambios del modelo que van a
  implicar que reaccione la interfaz gráfica.
• interface AgendaListener
• void alta (Contacto c)
• void baja (Contacto c)
• Las GUI que necesiten estar pendientes de estos
  cambios
• Implementarán el interfaz que especifica los
  eventos que va a notificar el modelo.
• public class GUIAgenda extends JFrame
• implements AgendaListener
• Se deben registrar en el controlador como oyentes
  del modelo.
• controlador.addAgendaListener(this)

13
Modelo de delegación de eventos

• El controlador notificará a sus oyentes cuando se
  produce un cambio en el modelo
• public void nuevoContacto(String nombre, String
  tfno)
• Contacto c new Contacto(nombre, tfno)
• //Actualizar el modelo
• agenda.añadir(c)
• //Informar a los oyentes del modelo
• //que se ha dado de alta un nuevo contacto
• Iterator it oyentesModelo.iterator()
• while (it.hasNext())
• ( (AgendaListener) it.next()).alta(c)
• La GUI se modificará en consecuencia

14
Principios de diseño

• Experto en Información Los objetos hacen las
  cosas relacionadas con la información que tienen.
• Creador Asignar a la clase B la responsabilidad
  de crear una instancia de clase A si se cumple
  uno o más de los siguientes casos
• B agrega objetos de A
• B contiene objetos de A
• B registra instancias de objetos de A
• B utiliza estrechamente objetos de A
• B tiene los datos de inicialización para la
  creación de los objetos de A
• Bajo Acoplamiento pocas interfaces.
• Alta Cohesión responsabilidades altamente
  relacionadas.

15
Algunas heurísticas

• Una clase representa una única abstracción bien
  definida.
• Cuidado con clases que tienen nombres
  operacionales (Mi clase hace ) son el
  resultado de convertir una rutina en una clase.
• Los atributos no son públicos.
• Métodos pequeños.
• Distribuir la funcionalidad horizontalmente.
• Cuidado con clases con muchos métodos set/get.
• Las clases del modelo deben ser independientes de
  las clases de la vista.
• Incluir clases controladores para coordinar la
  actividad, no incluir código del modelo en la
  vista.

16
Algunas heurísticas

• Factorizar comportamiento común lo más arriba que
  se pueda en la jerarquía de herencia.
• Crear tantas clases abstractas como sea posible.
• La clase raíz de una jerarquía de clases debería
  ser abstracta.
• Distribuir la funcionalidad horizontalmente.
• Favorecer jerarquías profundas.
• Minimizar colaboraciones.
• Composición antes que herencia de implementación.
• Cuidado con el uso de estructuras CASE.

17
Algunas heurísitcas

• Utilizar excepciones sólo para condiciones
  excepcionales.
• //NO HACER NUNCA ESTO
• try
• int i0
• while (true)
• ai.f()
• catch (ArrayIndexOutOfBoundsException e)
• Utilice excepciones comprobadas para condiciones
  recuperables y excepciones runtime para errores
  de programación.

18
Algunas heurísticas

• Favorezca el uso de excepciones predefinidas
• IllegalArgumentException
• NullPointerException
• IndexOutOfBoundsException
• NoSuchElementException
• UnsupportedOperationException
• Lance excepciones apropiadas al nivel de
  abstracción.
• Documentar todas las excepciones lanzadas por
  cada método (etiqueta _at_throws del javadoc)