Lto tema1

Índice

Introducción a la Programación
Orientada a Objetos
Introd. a la POO
El lenguaje Java
Estruct. Biblioteca
Excepciones
Colecciones Evolución de los lenguajes de programación
Entrada y salida Análisis de los sistemas complejos
GUIs Calidad del software.
Conceptos fundamentales de la P.O.O.

Laboratorio de Tecnología de Objetos I-1

Complejidad -> Caos -> Abstracción
Un médico, un ingeniero civil y una informática estaban discutiendo
acerca de cuál era la profesión más antigua del mundo.

El médico señaló: “Bueno, en la Biblia se dice que Dios creó a Eva de
una costilla que le quitó a Adán. Evidentemente, esto requirió cirugía, y
por eso bien puedo afirmar que la mía es la profesión más antigua del
mundo”.

El ingeniero interrumpió y dijo: “Pero incluso antes, en el Génesis, se
dice que Dios creó el orden de los cielos y la tierra a partir del caos. Esta
fue la primera y desde luego la más espectacular aplicación de la
ingeniería civil. Por tanto, querido doctor, está usted equivocado: la mía
es la más antigua profesión del mundo”.

La informática se reclinó en su silla, sonrió, y dijo tranquilamente: “Pero
bueno, ¿quién pensáis que creó el caos?”.
“Análisis y diseño orientado a objetos” Grady Booch


Evolución de los lenguajes de
A
B
programación A
B
S S
T
Lenguajes Id = Dir Mem. T
R
Cód.Inst.Simb. R
A Máquina / Manip.Total de A
C Macros
C Ensamblador Datos C
I C
Ó Id. Simb.
Subrutinas FORTRAN
I
N Tipos Ó
Funciones
O Oper. restring. N
P
E Registros D
R
Anidamiento PASCAL Tipos definidos E
A Subprogramas
C Gest. Din. Mem
D
I
O Encapsulam. Tipo A
N MODULA-2 T
Octult. Inform. Abstracto de
A ADA O
L Espec - Impl Datos S

Métodos Lenguajes Objetos
Mensajes Orientados a
Objetos

Evolución de los lenguajes de
A
B
programación A
B
S
T S
R Lenguajes Id = Dir Mem. T
A Cód.Inst.Simb. R
Máquina / Manip.Total de
C Macros A
C Ensamblador Datos C
I C
Ó Id. Simb.
N
Subrutinas FORTRAN
I
Tipos Ó
Funciones N
O Oper. restring.
P
E Registros D
R Anidamiento PASCAL E
Tipos definidos
A Subprogramas
C Gest. Din. Mem D
I A
O Encapsulam. Tipo T
N MODULA-2
Octult. Inform. Abstracto de O
A ADA S
L Espec - Impl Datos

Métodos Lenguajes
Mensajes Orientados a Objetos
Objetos

COMPONENTES
IDLs
ASPECTOS Componentes
Invocación remota


Análisis de los sistemas complejos

• Organismos vivos: • Organizaciones:

individuo multinacional
sistemas compañías
órganos divisiones
tejidos delegaciones
células oficinas locales


Análisis de sistemas reales
• Los sistemas complejos suelen tener una naturaleza jerárquica:
se pueden descomponer en partes que, a su vez, se descomponen
en otras partes, etc. Cada parte se corresponde con un nivel de
abstracción.
• El funcionamiento de un sistema, a cada nivel, se deriva de la
actividad colaboradora de sus partes en el nivel inferior.
• Los sistemas jerárquicos normalmente están compuestos de unas
pocas clases diferentes de subsistemas en distintas combinaciones
y disposiciones.
• La interacción entre subsistemas distintos suele ser pequeña en
comparación con la interacción dentro de cada subsistema.

Los sistemas jerárquicos se pueden analizar atendiendo a distintos
enfoques:
• la jerarquía estructural (es parte de ) y
• la jerarquía de tipos (es un).


Diseño de sistemas de software
• Cuando se diseña un sistema complejo de sw es esencial darle
una estructura jerárquica descomponiéndolo en partes.
• Esta organización puede hacerse desde distintos puntos de vista:
p.e. atendiendo al flujo de datos o a la interacción entre objetos.
• La descomposición algorítmica entiende cada sistema como un
proceso global y tiende a descomponerlo en subprocesos que
intercambian datos, fijando de forma rígida la estructura de
control (programas con estructura de árbol).
• La descomposición en objetos entiende cada sistema como un
conjunto de agentes autónomos que colaboran para llevar a cabo
un comportamiento de nivel superior (programas con estructura
de grafo).


Diseño orientado a objetos
• El diseño orientado a objetos surge de la idea de traspasar a los
sistemas de software la organización y el funcionamiento de los
sistemas reales complejos (físicos, biológicos, sociales, ...).

• La organización de los sistemas de software en objetos refleja el
análisis de
• la jerarquía estructural (en la disposición de los objetos) y
• la jerarquía de tipos (en la organización de las clases de
objetos) de los sistemas reales complejos.

• Esta organización es más fácil de mantener, es más versátil y
adaptable a nuevas necesidades del mismo sistema y además
permite la reutilización de las clases de objetos por otros sistemas.


Calidad del Software
• El propósito último de la Ingeniería del Software es encontrar
modos de construir software de calidad.
• La calidad de un sistema de software depende de un conjunto de
factores: factores externos y factores internos.
• Los factores externos son aquellos perceptibles por los usuarios
y clientes.
• Los factores internos son los perceptibles por los diseñadores e
implementadores.
• Los factores externos son los más importantes, pero sólo se
pueden alcanzar si se atiende a los factores internos.


Factores externos

• Corrección – Capacidad para realizar las tareas tal y como se
definen en las especificaciones.
• Eficiencia – Capacidad de requerir la menor cantidad posible de
recursos (tiempo de procesador, espacio de memoria, ancho de
banda, ...)
• Robustez – Capacidad para reaccionar apropiadamente ante
condiciones excepcionales.
• Extensibilidad – Facilidad de adaptación a los cambios en la
especificación.
• Reutilización – Capacidad de aplicación en la construcción de
sistemas muy diferentes.
• Compatibilidad – Facilidad para interactuar con otros sistemas.


Factores internos

• Los objetivos de extensibilidad, reutilización, e incluso los
referentes a la fiabilidad (corrección y robustez) requieren
arquitecturas flexibles para los sistemas de software.

• Las arquitecturas flexibles se consiguen con componentes
autónomos: módulos.

• La modularidad, fijada mediante una serie de criterios, es uno de
los factores internos más importantes .


Criterios de modularidad: condiciones

Descomposición modular - si facilita la tarea de descomponer el problema en
subproblemas menos complejos, interconectados mediante una estructura sencilla, y
suficientemente independientes para permitir que el trabajo futuro pueda proseguir
por separado en cada uno de ellos.
Composición modular - si favorece la producción de elementos de software que se
puedan combinar libremente para producir nuevos sistemas, en entornos diferentes
de aquél en que fueron desarrollados.
Comprensión - si ayuda a producir módulos fáciles de entender sin tener que
reconocer los demás, o teniendo que examinar sólo unos pocos.
Continuidad - si un pequeño cambio en la especificación de un problema provoca
sólo cambios en un número muy reducido de módulos.
Protección - si produce arquitecturas en las cuales el efecto de una situación anormal
producida dentro de un módulo durante la ejecución queda confinado a dicho módulo
o se propaga sólo a unos pocos vecinos.


Principios para asegurar la modularidad

Unidad modular lingüística –
Los módulos deben corresponderse con unidades sintácticas del lenguaje utilizado.
Interfaces explícitas –
Las interfaces deben ser públicas y claras.
Ocultación de información –
El diseñador de cada módulo debe poder seleccionar un subconjunto de propiedades
del módulo como información oficial sobre dicho módulo para ponerla a disposición
de los autores de módulos clientes.
Pocas interfaces –
Cada módulo debe comunicarse con el menor número posible de módulos.
Interfaces pequeñas –
Los módulos que se comunican deben intercambiar la menor información posible.


Factores, criterios y principios de
calidad del Software
FACTORES CRITERIOS
Interfaces
Explícitas
P
COMPATIBILIDAD DESCOMPOSICIÓN
DESCOMPOSICIÓN
R
COMPATIBILIDAD Unidad I
Modular
CORRECCIÓN Descomposición COMPOSICIÓN
COMPOSICIÓN Lingüíst N
CORRECCIÓN y C
Refinamientos Ocultación
Informac. I
ROBUSTEZ COMPRENSIÓN
COMPRENSIÓN
ROBUSTEZ P
Pocas
Modularidad interfaces I
REUTILIZACIÓN CONTINUIDAD
CONTINUIDAD O
REUTILIZACIÓN
Interfaces
pequeñas
S
EXTENSIBILIDAD
EXTENSIBILIDAD PROTECCIÓN
PROTECCIÓN


Conceptos básicos de la P.O.O.

Clases y Objetos.
Métodos y Mensajes.
Herencia.
Polimorfismo y Vinculación Dinámica.
Clases abstractas.
Clases genéricas.


Programación Orientada a los Objetos
Se basa en considerar un sistema de software como un universo de objetos que
colaboran en una tarea común intercambiando mensajes y en considerar, a su
vez, cada objeto como otro universo de objetos, etc.
Los programas se organizan como colecciones cooperativas de objetos, donde la
computación se realiza mediante el envío de mensajes.
Cada objeto es una abstracción dinámica de dato, instancia de una clase, que
tiene:
un comportamiento (dado por las operaciones que puede realizar: sus métodos),
un estado (el valor almacenado en su estructura interna), y
una identidad (invariante durante toda su existencia).
Cada clase describe la implementación de un tipo abstracto de datos; fija el
comportamiento y el estado de sus instancias, y es miembro de una jerarquía
construida mediante una relación de herencia.
La herencia es un orden parcial entre clases donde la precedencia representa
generalización y la sucesión especialización. Se implementa mediante un
mecanismo que facilita la construcción de clases por especialización heredando
atributos (estado y métodos) de las clases predecesoras en la jerarquía.


Clases y Objetos

• CLASE = MÓDULO + TIPO
Criterio de Modularización.
Estado + Comportamiento.
Entidad estática (en general).

• OBJETO = Instancia de una CLASE
Cada objeto tiene su propio estado.
Cada objeto tiene un comportamiento que es común a
todos los objetos de su clase.
Entidad dinámica.

Objeto vs. Clase Valor vs.Tipo

VEHÍCULO

ANIMAL

PUNTO

(1, 3)
(5, 2.5)
FIGURA (2, 2)
(2, 1)


Métodos y Mensajes
• Métodos: definen el comportamiento de una clase y
pueden o no comportar una respuesta
Punto Estado
x, y: double
trasladar(a, b) Comportamiento
distancia(pto)
• Mensajes: se construyen asociando un método a un
objeto (su destinatario)
• Paso de mensajes Invocación de métodos
obj.mens(args) mens(obj, args)
(Punto) pto
pto.trasladar(1, -1) x=12
y=32


Sobre el paso de mensajes
• Los mensajes que se envían a un determinado objeto deben
“corresponderse” con los métodos que hay definidos en su clase.
• Esta correspondencia se debe reflejar en la signatura del método:
nombre, argumentos y sus tipos.
• En los lenguajes orientados a objetos con comprobación de tipos,
la emisión de un mensaje a un objeto que no tiene definido el
método correspondiente se detecta en tiempo de compilación.
• Si el lenguaje no realiza comprobación de tipos, los errores en
tiempo de ejecución pueden ser inesperados.


Java
Definición de clase en Java

VARIABLES DE ESTADO
class Punto {
private double x, y; CONSTRUCTORES
public Punto() { x = y = 0; }
public Punto(double a, double b) { x = a; y = b; }
public double abscisa() {return x;}
“Punto.java”

public double ordenada() {return y;}
public void abscisa(double a){ x = a; } MÉTODOS
public void ordenada(double b){ y = b; }
public void trasladar(double a, double b) {
x += a; y += b;
}
public double distancia(Punto pto) {
return Math.sqrt(Math.pow(x - pto.x, 2) +
Math.pow(y - pto.y, 2));
}
} Laboratorio de Tecnología de Objetos I-21

C++
Definición de clase en C++
VARIABLES DE ESTADO
(DATOS MIEMBRO)
class Punto{
double x, y;
public: CONSTRUCTORES
Punto(){x = y = 0);}
“Punto.hpp”

Punto(double a, double b): x(a),y(b) {}
double abscisa() {return x;}
double ordenada() {return y;}
void abscisa(double a){ x = a; }
void ordenada(double b){ y = b; }
void trasladar(double a, double b);
double distancia(Punto&);
};
MÉTODOS
(FUNCIONES MIEMBRO)

C++

#include “Punto.hpp”
#include <math.h>

void Punto::trasladar(double a, double b) {
x += a;
y += b;
“Punto.cpp”

};

double Punto::distancia(Punto& pto){
return sqrt(pow(x - pto.x, 2) +
pow(y – pto.y, 2));
};


class Punto
ATRIBUTOS Eiffel
creation origen, nuevo;
feature
x, y: REAL; CONSTRUCTORES
origen is do x := 0; y := 0 end;
nuevo(a, b: REAL) is
do x := a; y := b end;
abscisa(a: REAL) is
do x := a end;
ordenada(b: REAL) is
do y := b end;
trasladar(a, b: REAL) is
do x := x + a; y := y + b end;
distancia(pto: Punto): REAL is
do
Result := sqrt(pow(x - pto.x, 2)
+ pow(y - pto.y, 2))
end
end Punto; RUTINAS

Smalltalk
Object subclass: #Punto
instanceVariableNames: ‘ x y ’
classVariableNames: "
poolDictionaries: " Métodos de clase
origen
^(self new) abscisa: 0; ordenada: 0
x: unNum y: otroNum
^(self origen) tras: unNum ladar: otroNum
abscisa
^x
ordenada
^y
abscisa: unNum
x := unNum
ordenada: unNum
y := unNum Métodos de instancia
tras: unNum ladar: otroNum
x := x + unNum. y := y + otroNum
distancia: unPunto
^ ((x - unPunto abscisa) squared +
(y - unPunto ordenada) squared) sqrt

Clases vs. tipos abstractos de datos

Una clase en un LOO se puede ver como una posible
implementación de un tipo abstracto de datos, donde:
• Los constructores se corresponden con métodos de creación de
instancias.
• Las funciones selectoras se corresponden con variables de estado
o con métodos que devuelven algún resultado.
• Las funciones de transformación se corresponden con métodos
que no devuelven valor (devuelven void, en C++ y Java, o son
procedimientos, en Eiffel), en los que el argumento que
representa el valor del tad que se transforma se omite.


El tad Pila en Maude
fmod PILA [X :: TRIV] is
sort Pila[X] PilaNv[X] .
subsort PilaNv[X] < Pila[X] .
op pilaVacía : -> Pila[X] [ctor] .
op apilar : Elt.X Pila[X] -> PilaNv[X] [ctor] .
op desapilar : PilaNv[X] -> Pila[X] .
op cima : PilaNv[X] -> Elt.X .

var N : Elt.X . var P : Pila[X] .

eq desapilar(apilar(N, P)) = P .
eq cima(apilar(N, P)) = N .
endfm


Una clase Pila en Java
class Pila<T>{
...
// Parte privada con los detalles de implementación
...
public Pila() { … }
public T cima() { … }
public void apilar(T elem) { … }
public void desapilar() { … }
...
}


Herencia
FiguraCerrada

• Posibilidad de reutilizar código
• Algo más que:
incluir ficheros, o Polígono Elipse
importar módulos
• Distintos tipos de herencia:
simple / múltiple
Pentágono Cuadrilátero Círculo
estricta / no estricta
selectiva / no selectiva
de implementación / de interfaz
Rectángulo Rombo


Herencia

Padres / Ascendiente /
Superclases • Una subclase hereda (dispone de) los
atributos y métodos de la superclase, y
Exception
puede añadir otros nuevos.
• La subclase puede modificar el
comportamiento heredado (p. e.,
redefiniendo algún método heredado) .
IOException • La herencia es transitiva.
• Los objetos de una clase que hereda de
Hijos / Descendientes / otra pueden verse como objetos de esta
Subclases última (polimorfismo de datos).


Java
class Partícula extends Punto {
protected double masa;
final static double G = 6.67e-11;
public Partícula(double m) {
super(0,0);
masa = m;
}
public Partícula(double a, double b, double m) {
super(a,b);
masa = m;
}
public void masa(double m) {masa = m; }
public double masa() {return masa; }
public double atracción(Partícula part) {
double d = this.distancia(part);
return G * masa * part.masa() / (d*d);
}
}

C++

class Particula: public Punto {
protected double masa;
const double G = 6.67e-11;
public:
Particula(double m):
Punto()
“Particula.hpp”

{ masa = m; };
Particula(double a, double b, double m):
Punto(a, b)
{ masa = m; };
void masa(double);
double masa();
double atraccion(Particula&);
};


C++

#include “Partic.hpp”

void Particula::masa(double m) {
masa = m;
}
“Particula.cpp”

double Particula::masa() {
return masa;
}

double Particula::atraccion(Particula& part){
double d = this -> distancia(part);
return G *masa* part.masa() / (d*d);
}


Eiffel

class Particula
inherits Punto
creation nueva;
feature
masa: REAL;
nueva(a, b, m: REAL) is
do x := a; y := b; masa := m end;
masa(m: REAL) is
do masa := m end;
atraccion(part: Particula): REAL is
do d := Current.distancia(part);
Result := G*masa*part.masa/(d*d)
end
end Particula;


Smalltalk
Punto subclass: #Particula
instanceVariableNames: ‘ masa ’
classVariableNames: "
poolDictionaries: "

x: abs y: ord masa: mas
^(self x: abs y: ord) masa: mas

masa
^masa
masa: unNum
masa := unNum
atraccion: unaPart
^ G * masa * (unaPart masa) /
((self distancia: unaPart) squared)


Herencia estricta y no estricta
• Cuando no se admite la redefinición de un método en el contexto de la
clase heredera, la herencia se denomina estricta.
• En herencia no estricta las clases herederas pueden heredar un método
o servicio y luego, redefinirlo modificando su implementación.

Suma de distancias entre
Polígono puntos consecutivos Cuadrado

lado: float

perímetro( ): double Resultado = 4 * lado perímetro( ): double

• Todos los lenguajes comerciales permiten redefinición (herencia
no estricta) por defecto.
• Sin embargo, en Java se pueden declarar métodos y atributos
como final, impidiendo que sus herederos los redefinan.

Herencia selectiva y no selectiva
• Cuando existe alguna posibilidad de seleccionar sólo parte
de las características heredadas, rechazando el resto
hablamos de herencia selectiva.

• Si, por el contrario, al heredar una clase no es posible
descartar ninguno de sus elementos, se trata de herencia
no selectiva.

• En general, lo habitual es encontrar herencia no selectiva,
aunque hay lenguajes, como Eiffel, en los que existen
algunas variantes de este mecanismo.


Herencia simple y múltiple

• Existen lenguajes con herencia múltiple, lo que permite
que una clase reutilice la funcionalidad ofrecida por
varias clases.
Pensionista TrabajadorActivo

MedioPensionista

• Lenguajes con herencia múltiple: C++, Eiffel
• Lenguajes con herencia simple: Java, Smalltalk


Herencia múltiple: ambigüedades

• La herencia múltiple produce el problema de la herencia
repetida.
Pensionista TrabajadorActivo

pensión salario

calcularIRPF( ): short calcularIRPF( ): short

elAbuelo: MedioPensionista calcularIRPF( )

• Conflicto por ambigüedad (atributos o métodos)


Herencia múltiple: duplicación de atributos

• Se produce en lenguajes, como C++, en los que la reserva
de memoria al crear instancias se realiza sin tener en
cuenta el grafo de herencia: Persona
nombre:String

elAbuelo: MedioPensionista
¡!
Pensionista::nombre Pensionista TrabajadorActivo
pensión: Float salario: Float
TrabajadorActivo::nombre
pensión
salario

MedioPensionista


Herencia simple: redefinición

• La herencia simple puede permitir la redefinición de
métodos y atributos.
• En tales casos se produce una situación de ambigüedad
a la hora de invocar un método o un atributo
redefinido.
• Estas situaciones se suelen resolver recorriendo el árbol
de la herencia hacia arriba.


Resolución de ambigüedades
• Las ambigüedades en herencia simple se producen por la
redefinición cuando en el contexto de un objeto hay dos posibles
definiciones para resolver un método y se resuelven aplicando la
más próxima a la clase a la que pertenece el objeto (recorriendo el
árbol de herencia hacia arriba).
• El problema de las ambigüedades en los métodos producidas por la
herencia múltiple surge por la necesidad de localizar la definición
adecuada en un grafo, en lugar de en un árbol (como ocurre en
herencia simple).
• En el caso de la herencia múltiple, no se encuentran soluciones
adecuadas a todas las situaciones basadas en recorridos del grafo
Primero en profundidad (de izquierda a derecha, o de derecha a izquierda)
Primero en amplitud (de izquierda a derecha, o de derecha a izquierda)


Soluciones a la herencia repetida
• C++:
Duplicación de atributos: herencia virtual
Ambigüedades: operador de ámbito
• Eiffel:
Ambigüedades: renombramiento de métodos y/o atributos
• Smalltalk:
No hay herencia múltiple
• Java:
Herencia de interfaces


Polimorfismo (sobre los datos)
• Un lenguaje tiene capacidad polimórfica sobre los datos cuando una
variable declarada de un tipo (o clase) –tipo estático– determinado
puede hacer referencia en tiempo de ejecución a valores (objetos) de
tipo (clase) distinto –tipo dinámico –.
• La capacidad polimórfica en los lenguajes orientados a objetos sólo
se aplica a las referencias a objetos y, normalmente, está restringida
por la relación de herencia: el tipo dinámico debe ser descendiente
del tipo estático.
En Java, Eiffel y Smalltalk, cualquier variable es una referencia a un objeto.
En C++ se distingue entre objetos y punteros a objetos. El polimorfismo sólo
se puede aplicar a estos últimos.
En Smalltalk, como no hay declaración de tipos, se puede pensar en un
polimorfismo total.


Polimorfismo (sobre los datos)
• Una variable puede referirse a objetos de clases distintas de la que
se ha declarado. Esto afecta a:
Las asignaciones explícitas entre variables
Los receptores de mensajes
Los parámetros de mensajes
Los resultados de mensajes.

• La restricción dada por la herencia permite construir estructuras
con elementos de naturaleza distinta, pero con un comportamiento
común:


Java

Punto pto = new Punto();
Partícula part = new Partícula(2);

pto = part; // Asignación correcta
part = pto; // Asignación incorrecta
part = (Partícula)pto; // Peligroso

part pto

(Partícula)
x=0
(Partícula) (Punto) m = ??
y=0
x=0 x=0
m=2
y=0 y=0


C++

Punto *ppto = new Punto();
Particula *ppart = new Partícula(2);

ppto = ppart; // Asignación correcta
ppart = ppto; // Asignación incorrecta
ppart = (Partícula*)ppto; // Más peligroso que en Java

ppart ppto

(Particula)
(Particula) x=0
(Punto) m = ??
y=0
x=0 x=0
m=2
y=0 y=0


Vinculación dinámica
• La vinculación dinámica resulta el complemento indispensable del
polimorfismo sobre los datos, y consiste en que: la invocación del
método que ha de resolver un mensaje se retrasa al tiempo de
ejecución, y se hace depender del tipo dinámico del objeto receptor.
Polígono :Polígono
perímetro{^...}
obj : Polígono

Cuadrado :Cuadrado perím
etro?
perímetro{^4*lado}
• En general, todos los lenguajes orientados a objetos establecen por
defecto un mecanismo de vinculación dinámica para resolver los
mensajes. No obstante, algunos de ellos (C++) necesitan etiquetar de forma
explícita las funciones que han de resolverse dinámicamente: funciones virtual.


Java

class PuntoAcotado extends Punto {
private Punto esquinaI, esquinaD;
public PuntoAcotado(){…}
public PuntoAcotado(Punto eI, Punto eD){…}
public double ancho(){…}
public double alto(){…}
public void trasladar(double a, double b){
double excesoX, excesoY;
excesoX = (abscisa()+a-esquinaI.abscisa()) %ancho();
excesoY = (ordenada()+b-esquinaI.ordenada()) %alto();
abscisa(excesoX + (excesoX>0 ? esquinaI.abscisa() :
esquinaD.abscisa()));
ordenada(excesoY + (excesoY>0 ? esquinaI.ordenada() :
esquinaD.ordenada()));
}
}


Java
PuntoAcotado pac
V
I class Punto { x==01
x
N private double x, y; y==01
y
C public Punto(){…} pto
U …
L public void
trasladar(double a, double b)

tra
A
C {x += a; y += b; }

sla
I public double distancia(Punto p){…}
Ó };

dar
N

(3,
D Punto eI = new Punto(0,0);
I

3)
Punto eD = new Punto(2,2);
N
Á Punto pto;
M PuntoAcotado pac = new PuntoAcotado(eI,eD);
I pto = pac;
C
A pto.trasladar(3,3);


C++
class PuntoAcotado: public Punto {
Punto esquinaI,esquinaD;
public:
PuntoAcotado(Punto eI, Punto eD);
double ancho();
double alto();
};
void PuntoAcotado::trasladar(double a, double b) {
double excesoX, excesoY;
excesoX = (abscisa()+a-esquinaI.abscisa()) % ancho();
excesoY = (ordenada()+b-esquinaI.ordenada()) % alto();
if (excesoX > 0) incX = esquinaI.abscisa();
else incX = esquinaD.abscisa();
if (excesoY > 0) incY = esquinaI.ordenada();
else incY = esquinaD.ordenada();
abscisa(excesoX + incX);
ordenada(excesoY + incY);
} Laboratorio de Tecnología de Objetos I-51

C++
class Punto { PuntoAcotado ppac
V
double x, y; x= 0
3
I
public: y= 0
3
N
Punto();
C
Punto(double a, double b);
ppto
U
~Punto();
L
…

tra
A
C
double distancia(Punto& pp);

sla
I
};
Ó

dar
N
Punto *eI = new Punto(0,0);

(3,
E Punto *eD = new Punto(2,2);
S

3)
T
Á Punto *ppto;
T PuntoAcotado *ppart = new PuntoAcotado(eI,eD);
I ppto = ppac;
C
A ppto->trasladar(3,3);


C++
class Punto { PuntoAcotado ppac
V
float x, y; x= 0
1
I
public: y= 0
1
N
Punto();
C
Punto(double a, double b);
ppto
U
~Punto();
L
…

tra
A
virtual void trasladar(double a, double b);
C
double distancia(Punto& pp);

sla
I
};
Ó

dar
N
Punto *eI = new Punto(0,0);

(3,
D Punto *eD = new Punto(2,2);
I

3)
N
Á Punto *ppto;
M PuntoAcotado *ppart = new PuntoAcotado(eI,eD);
I ppto = ppac;
C
A ppto->trasladar(3,3);


Composición/agregación

• Además de la relación de herencia, existe otra relación básica entre clases,
denominada “composición”.
• Mientras que la herencia establece una relación de tipo “es-un”, la composición
responde a una relación de tipo “está compuesto de”.
• Así, por ejemplo, una partícula es un punto (con masa), mientras que un
segmento está compuesto por dos puntos (origen y extremo)

Partícula Punto origen Segmento

masa: double x, y: double
atracción(part) trasladar(a, b) extremo trasladar(a, b)
distancia(pto) longitud()


class Segmento {
private Punto origen, extremo;
public Segmento(double x1, double y1, double x2, double y2) {
origen = new Punto(x1, y1);
extremo = new Punto(x2, y2);
}

... // Otros métodos

public double longitud() {
return origen.distancia(extremo);
}
}


Ejemplo de análisis O.O.
Vuelta ciclista por etapas:


Clases abstractas

• Clases con funciones sin implementar
funciones abstractas en Java
funciones virtuales puras en C++
rutinas “deferred” en Eiffel
métodos “implementedBySubclass” en Smalltalk
• No es posible crear instancias (objetos)
• Se puede declarar variables (que se referirán, en tiempo de
ejecución, a objetos de clases descendientes)
punteros a objetos en C++


Java
CLASE ABSTRACTA
abstract class Polígono {
private Punto[] vértices;
public void trasladar(double a, double b){
for (int i = 0; i < vértices.length; i++)
vértices[i].trasladar(a, b);
}
public double perímetro() {
double per = 0;
for (int i = 1; i < vértices.length; i++)
per = per + vértices[i-1].distancia(vértices[i]);
return per +
vértices[0].distancia(vértices[vértices.length]);
}
abstract public double área();
};
MÉTODO ABSTRACTO

Polígono pol = new Polígono();

Abstracción/concreción
• Las clases abstractas definen un protocolo común a una
jerarquía de clases.
• Se concretan mediante la herencia.
• Obligan a sus subclases a implementar los métodos
abstractos (de lo contrario, las subclases siguen siendo abstractas).

En Java, también se pueden definir interfaces
• Sin estado y con todos los métodos sin implementar.
• Se concretan mediante implementación.
• Una clase puede implementar varias interfaces.


Clases genéricas
• Las clases genéricas responden a patrones comunes de
comportamiento.
• Permiten definir las operaciones de una clase de forma
independiente del tipo de datos que manipula.
• Clases y/o Tipos como parámetros (con o sin restricciones).
• Instanciación directa.
Pila
TipoBásico <Polígono>
Pila
cima: TipoBásico
apilar(TipoBásico): void
desapilar(): void Pila
esVacía: boolean <int>


Formas de genericidad
• Genericidad basada en el polimorfismo debido a la herencia.
El programador debe controlar los tipos de las componentes .
El control se retrasa al tiempo de ejecución.
• Genericidad basada en el uso de parámetros (clases, tipos básicos,
valores, etc.)
El control del tipo de las componentes se realiza en tiempo de compilación.
• Los lenguajes orientados a objetos permiten la definición de clases
genéricas mediante variaciones de estos mecanismos:
Eiffel (clases parametrizadas)
C++ (templates que simulan clases parametrizadas)
Java (basada en la jerarquía de clases y en las interfaces, y a partir de JDK
1.5 se permiten clases parametrizadas con clases o interfaces).
Smalltalk (no tiene sentido al no ser un lenguaje con tipos)


Persistencia
• Durante la ejecución de un programa o.o. los objetos se van
creando y destruyendo.
• La persistencia se refiere a la capacidad de ciertos objetos
que perduran mas allá de la vida de la aplicación que los crea.
• Permite que un mismo objeto sea utilizado por diferentes
aplicaciones manteniendo su identidad y relaciones.
• Es muy útil en aplicaciones de:
Base de datos
Movilidad
Etc.


Lto tema1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Lto tema1

Ähnlich wie Lto tema1 (20)

Mehr von Aldo Hernán Zanabria Gálvez

Mehr von Aldo Hernán Zanabria Gálvez (20)

Lto tema1