Java-Clases Abstractas e Interfaces - Inicio

Transcripción

Java: Clases Abstractas e Interfaces
Franco Guidi Polanco
Escuela de Ingeniería Industrial
Pontificia Universidad Católica de Valparaíso, Chile
[email protected]
Clases abstractas e interfaces
v A nivel conceptual, las clases abstractas e interfaces
permiten definir qué puede hacer un conjunto o familia de
clases relacionadas.
v Ejemplo en el contexto de la universidad:
Las “personas” (esto es,
“alumnos”, “profesores” y
“administrativos”)
conocen y retornan su
RUT, nombre, teléfono y
dirección
Persona
Alumno
Profesor
Administrativo
25-05-14
2
Clases Abstractas
v  Una clase es declarada abstracta cuando no
es posible crear instancias de ella.
v  Una clase debe ser declarada abstracta si
posee al menos un método declarado
abstracto.
v  Un método abstracto es aquél que no provee
implementación.
Pablo Picasso, Toro (11)
v  Una subclase de una clase abstracta
puede ser instanciada (es decir, puede
ser “no abstracta”) sólo si provee
implementación para todos los
métodos abstractos de la superclase.
En caso contrario, debe también ser
declarada abstracta.
25-05-14
3
Ejemplo de Clase Abstracta
public abstract class Poligono {
int lados;
public int setLados(int l){
lados = l;
}
public abstract double getArea();
...
}
public class Cuadrado extends Poligono {
int longitud;
public double getArea(){
return longitud*longitud;
}
...
}
25-05-14
Clase abstracta
Polígono
Clase concreta
que extiende la
clase abstracta.
4
Interfaces
v En ocasiones, en vez de implementar herencia, es posible
implementar interfaces.
v Una interfaz define un tipo de dato. Esta definición
especifica el identificador de un tipo y declara los métodos
que el tipo provee (sin implementación).
v Las interfaces son frecuentemente descritas como
contratos: una interfaz garantiza que una clase proveerá
cierta funcionalidad, pero sin especificar cómo esta
funcionalidad será implementada.
v La implementación de interfaces se conoce también como
herencia por contrato o herencia de interfaces. En estos
casos sólo se hereda la interfaz, no hay herencia de
funcionalidad.
25-05-14
5
Interfaces en Java
v Contenido de una interfaz:
§  Nombre y visibilidad
§  Eventuales otras interfaces
extendidas
§  Declaraciones de métodos
§  Constantes (declaradas como
static final)
v Una interfaz no provee:
§  Variables de instancia o de clase
§  Implementación para los
métodos
v Útiles cuando una clase debe usar objetos de distintas
clases, pero que operan de la misma forma (ej. un
temporizador para videograbador, radio, etc.)
25-05-14
6
Analogía
Destornillador
Clase que debe usar ciertos
objetos
Modelos de cabezas
De tornillos
Interfaces
Clases que implementan
alguna de las interfaces
Tornillos
25-05-14
7
Ejemplo de Interfaz
public interface Despertable {
public static final int DORMIDO = 1;
public static final int DESPIERTO = 2;
public void despierta();
}
public class Persona implements Despertable{
int estado = DESPIERTO;
public void dormir() {
estado = Despertable.DORMIDO;
}
public void despierta(){
estado = DESPIERTO;
}
...
}
25-05-14
La interfaz
Despertable
Una clase que
implementa la
interfaz
Despertable
8
Ejemplo de Interfaz (cont.)
public class Alarma {
...
public static void despertar(Despertable d){
d.despierta();
}
}
La Alarma es
capaz de “despertar”
cualquier objeto
que implemente la
interfaz
Despertable.
public class Ejemplo {
public static void main(String[] arg){
Persona p1 = new Persona();
Alarma.despertar(p1);
Despertable p2 = new Persona();
Alarma.despertar(p2);
}
}
25-05-14
9
Uso de Interfaces
v Una clase puede implementar múltiples interfaces:
public class Anfibio implements Terrestre, Acuático { ... }
v Una interfaz puede extender otras interfaces.
public interface Anfibio extends Terrestre, Acuático { ... }
v Algunos enuncian que el uso de interfaces representa una
forma de enfrentar el problema de la “herencia múltiple” en
Java.
25-05-14
10
Interfaces y excepciones
v Las excepiones declaradas en los métodos de una
interfaz (cláusula throws) también deben ser
declaradas en los métodos de las clases que
implementan la interfaz.
25-05-14
11
Interfaces y clases abstractas: aspectos comunes
v Tanto clases abstractas como interfaces necesitan
implementación en otras clases, para sus
propiedades abstractas:
§  Clases abstractas: requieren subclase(s).
§  Interfaces: requieren clase(s) que implemente(n) la
interfaz.
25-05-14
12
Ejemplo
v  El Aerosub (“Viaje al fondo del mar”)
public interface Aéreo {
public void despegar();
public void acuatizar();
}
public interface Acuático {
public void emerger();
public void sumergirse();
}
public class Aerosub implements Aéreo, Acuático{
public void despegar(){…}
public void acuatizar(){…}
public void emerger(){…}
public void sumergirse(){…}
}
25-05-14
13
Ejemplo (cont.)
v  Clase que accede a las funciones del Aerosub:
public class Comandante {
public Aerosub vehículo;
public Comandante(Aerosub v){
vehículo = v;
}
public void comandar(){
…
vehículo.emerger();
…
vehículo.despegar();
…
vehículo.acuatizar();
…
vehículo.sumergirse();
…
}
}
25-05-14
14
Ejemplo (cont.)
v  Clases que acceden al Aerosub con funcionalidades limitadas:
public class Aviador {
public class Marino {
public Aéreo vehículo;
public Acuático vehículo;
public Aviador(Aéreo v){
vehículo = v;
}
public Marino(Acuático v){
vehículo = v;
}
public void pilotear(){
…
vehículo.despegar();
…
vehículo.acuatizar();
…
}
public void navegar(){
…
vehículo.sumergirse();
…
vehículo.emerger();
…
}
}
}
25-05-14
15
Atención en el uso de la herencia e implementación de
Interfaces
v  Deben considerarse relaciones con valor semántico en el dominio del
problema. Ejemplos como este pueden no tener sentido:
public class ReyDeLaSelva implements Elefante, Pistola
A menos que…
25-05-14
16
Ejercicio 1
v  Una empresa desarrolladora de software de monitoreo debe crear aplicaciones
capaces de obtener datos desde distintos tipos de sensores (de contaminación
por partículas, ruido, voltaje, etc.) y mostrar dichos valores por pantalla. Cada
aplicación se desarrolla para trabajar con un tipo de sensor. Los sensores son
manejados por clases específicas (e.g. TemperatureSensor, DustSensor, etc.) y
proveen tres métodos: (1) un método para activarlo; (2) un método que
retorna un double correspondiente al valor percibido por el sensor en el
momento; y (3) un método para desactivarlo.
Los siguientes son ejemplos de aplicaciones desarrolladas por esta empresa:
Para manejar un
sensor de
Temperatura
public class Muestra {
public static void main( String[] arg ){
TempSensor t = new TempSensor();
t.activa();
for(int i=0; i<10000; i++ )
System.out.println( t.leeTemp() );
t.desactiva();
}
}
25-05-14
17
Ejercicio 1 (cont.)
Para manejar un
sensor de polvo
ambiental
public class Muestra {
public static void main( String[] arg ){
DustSensor t = new DustSensor();
t.on();
for(int i=0; i<10000; i++ )
System.out.println( t.readMeasure() );
t.off();
}
}
A pesar de lo similar de las aplicaciones, en cada ocasión es necesario reescribir
no sólo la clase de sensor que se utilizará, sino también las invocaciones
correspondientes a sus métodos específicos, lo cual hace el desarrollo
ineficiente.
Se pide determinar una arquitectura que permita a la empresa simplificar su
trabajo de desarrollo.
25-05-14
18
Ejercicio 2
v Diseñe y programe las clases e interfaces que permiten
resolver el siguiente problema:
§  Se desea construir una clase que permita mantener una colección
de objetos ordenados ascendentemente.
§  Los objetos a ordenar pueden ser de cualquier clase. Los objetos
deberán implementar un método que permita determinar si un
objeto es mayor que otro.
25-05-14
19
La necesidad de clases abstractas e interfaces
Situación 1:
v  Contexto: se está desarrollando una
aplicación que trabaja con CD’s,
DVD’s y discos de vinilo.
ProductoMusical
{abstract}
v  Problema: se establece que a pesar
de tener sus propios atributos, todos
ellos disponen de código, sello
discográfico y autor. Se desea evitar
duplicidad de código.
v  Decisión: se determina la
conveniencia de crear la clase
“ProductoMusical”, que agrupa las
propiedades comunes de los tres
tipos de productos. La clase
ProductoMusical no es instanciable,
por lo tanto se lo declara abstracto.
25-05-14
código
sello
autor
CD
DVD
Vinilo
La superclase aparece por factorización
de propiedades comunes
20
La necesidad de clases abstractas e interfaces
(cont.)
Situación 2:
La superclase o interfaz
es impuesta a las subclases.
v  Contexto: se está desarrollando una
clase Timer para programar distintos
objetos temporizables (ej. relojes,
grabadoras, alarmas, etc.)
v  Problema: Los objetos temporizables
pueden ser distintos, y al momento
de desarrollar el Timer no se sabe
exactamente de qué clase son.
v  Decisión: se define una interfaz (o
una clase abstracta, si hay código en
común) que implementarán todos
los objetos temporizables. El Timer
accede a los objetos temporizables a
través de esta interfaz.
25-05-14
Timer
Temporizable
{abstract}
Reloj
Grabadora
21
Discusión
v Tanto clases abstractas como
interfaces permiten describir
propiedades comunes de
familias de clases.
¿Cuándo conviene utilizar unas
u otras?
25-05-14
22
Caso de estudio: Mars Climate Orbiter
v Mars Climate Orbiter (MCO)
v Vehículo espacial de la NASA, enviado a Marte para
recolectar información
v Se perdió el 23 de septiembre de 1999 durante la maniobra
de inserción en la órbita de Marte.
v Se sospecha que se estrelló en Marte o que ingresó a una
trayectoria heliocéntrica.
25-05-14
23
v  Varias irregularidades en la trayectoria se detectaron durante la
navegación de 9 meses desde la Tierra hacia Marte.
v  Durante el inicio del proceso de inserción en la órbita de Marte
se observó que el MCO se encontraba 170 km bajo lo planeado
v  El ingreso a la zona de “ocultamiento” en la órbita de Marte
ocurrió 49 segundos antes de lo previsto. No se reestableció
comunicación tras los 21 minutos predichos como duración el
ocultamiento.
v  El 25 de septiembre de 1999 cesaron los intentos por
reestablecer comunicación con la nave.
v  El 29 de septiembre se descubrió que las variables denominadas
“small forces”, utilizadas en los modelos de cálculo de la órbita
de los sistemas de tierra, tenían un valor 4,45 veces más
pequeño de lo debido.
25-05-14
24
v  Los valores eran más pequeños porque, de acuerdo con lo indicado en
las especificaciones de la interfaz de software, el sistema de
navegación en tierra consideraba datos de entrada expresados en
Newton-seg (sistema Métrico), en cambio éstos eran equivocadamente
proporcionados por otro módulo de software en libras_fuerza-seg
(sistema Inglés).
v  Notar que: 1 libra fuerza = 4,45 Newton
Gráfico: “Mars Climate Orbiter”
Mishap Investigation Board.
November 10, 1999, NASA.
25-05-14
25
v Causas:
§  Inadecuada visión sistémica sobre la completa misión.
§  Falta de una adecuada comunicación entre equipos de
desarrollo.
§  Falta de una acuciosa verificación del software de
navegación, y de los modelos computacionales
relacionados.
25-05-14
26

Java-Clases Abstractas e Interfaces - Inicio

Transcripción

Documentos relacionados

Para presentar el examen oral, usted puede llegar desde: el Metro