Introducción a la Programación Orientada a Objetosjmmb/lto/LTO-Tema1.pdf · Orientada a Objetos...

Laboratorio de Tecnología de Objetos I-1

Introducción a la Programación Orientada a Objetos

Evolución de los lenguajes de programaciónAnálisis de los sistemas complejosCalidad del software.Conceptos fundamentales de la P.O.O.

Introd. a la POOEl lenguaje JavaEstruct. BibliotecaExcepcionesColeccionesEntrada y salidaGUIs

Índice


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

Complejidad -> Caos -> Abstracción


Evolución de los lenguajes de programaciónA

BSTRACCIÓN

OPERACIONAL

ABSTRACCIÓN

DE

DATOS

LenguajesMáquina /

Ensamblador

Cód.Inst.Simb.Macros

Id = Dir Mem.Manip.Total de

Datos

FORTRANSubrutinasFunciones

Id. Simb.Tipos

Oper. restring.

PASCALAnidamientoSubprogramas

RegistrosTipos definidosGest. Din. Mem

MODULA-2ADA

Encapsulam.Octult. Inform.

Espec - Impl

TipoAbstracto de

Datos

LenguajesOrientados a

Objetos

ObjetosMétodosMensajes


Evolución de los lenguajes de programación

COMPONENTESASPECTOS

ABSTRACCIÓN

OPERACIONAL

ABSTRACCIÓN

DE

DATOS

LenguajesMáquina /

Ensamblador

Cód.Inst.Simb.Macros

Id = Dir Mem.Manip.Total de

Datos

FORTRANSubrutinasFunciones

Id. Simb.Tipos

Oper. restring.

PASCALAnidamientoSubprogramas

RegistrosTipos definidosGest. Din. Mem

MODULA-2ADA

Encapsulam.Octult. Inform.

Espec - Impl

TipoAbstracto de

Datos

LenguajesOrientados a

Objetos

MétodosMensajes Objetos

IDLsInvocación remota Componentes


Análisis de los sistemas complejos

• Organismos vivos:

individuosistemasórganostejidoscélulas

• Organizaciones:

multinacionalcompañíasdivisionesdelegacionesoficinas locales


• 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.

Análisis de sistemas reales

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).


• 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 de sistemas de software


• 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.

Diseño orientado a objetos


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

PRINCIPIOS

CRITERIOS

CORRECCIÓNCORRECCIÓN

EXTENSIBILIDADEXTENSIBILIDAD

COMPATIBILIDADCOMPATIBILIDAD

REUTILIZACIÓNREUTILIZACIÓN

ROBUSTEZROBUSTEZ

Descomposicióny

Refinamientos

Modularidad

COMPRENSIÓNCOMPRENSIÓN

COMPOSICIÓNCOMPOSICIÓN

DESCOMPOSICIÓNDESCOMPOSICIÓN

CONTINUIDADCONTINUIDAD

PROTECCIÓNPROTECCIÓN

InterfacesExplícitas

UnidadModularLingüíst

OcultaciónInformac.

Pocasinterfaces

Interfacespequeñas


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 ObjetosSe 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 lacomputació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 + TIPOCriterio de Modularización.Estado + Comportamiento.Entidad estática (en general).

• OBJETO = Instancia de una CLASECada 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


(1, 3)

(2, 2)(2, 1)

(5, 2.5)

ANIMAL

VEHÍCULO

FIGURA

PUNTO


(Punto)x = 1y = 3

(Punto)x = 2y = 2

• Métodos: definen el comportamiento de una clase y pueden o no comportar una respuesta

• Mensajes: se construyen asociando un método a un objeto (su destinatario)

• Paso de mensajes Invocación de métodosobj.mens(args) mens(obj, args)

Punto

x, y: double

trasladar(a, b)distancia(pto)

Estado

Comportamiento

pto.trasladar(1, -1)

Métodos y Mensajes

pto


• 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.

Sobre el paso de mensajes


Definición de clase en Java

class Punto {private double x, y;public Punto() { x = y = 0; }public Punto(double a, double b) { x = a; y = b; }public double abscisa() {return x;}public double ordenada() {return y;}public void abscisa(double a){ x = a; }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));

}}

“Pun

to.ja

va”

VARIABLES DE ESTADO

CONSTRUCTORES

Java

MÉTODOS


class Punto{double x, y;

public:Punto(){x = y = 0);}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&);

};

“Pun

to.h

pp”

VARIABLES DE ESTADO(DATOS MIEMBRO)

MÉTODOS(FUNCIONES MIEMBRO)

CONSTRUCTORES

C++

Definición de clase en C++


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

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

};

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

pow(y – pto.y, 2)); };

“Pun

to.c

pp”

C++


class Puntocreation origen, nuevo;feature

x, y: REAL;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

doResult := sqrt(pow(x - pto.x, 2)

+ pow(y - pto.y, 2))end

end Punto;

ATRIBUTOS

RUTINAS

Eiffel

CONSTRUCTORES


Object subclass: #PuntoinstanceVariableNames: ‘ x y ’classVariableNames: "poolDictionaries: "

origen^(self new) abscisa: 0; ordenada: 0

x: unNum y: otroNum^(self origen) tras: unNum ladar: otroNum

abscisa^x

ordenada^y

abscisa: unNumx := unNum

ordenada: unNumy := unNum

tras: unNum ladar: otroNumx := x + unNum. y := y + otroNum

distancia: unPunto^ ((x - unPunto abscisa) squared +

(y - unPunto ordenada) squared) sqrt

Smalltalk

Métodos de clase

Métodos de instancia


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 estadoo 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] issort 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

• Posibilidad de reutilizar código• Algo más que:

incluir ficheros, o importar módulos

• Distintos tipos de herencia:simple / múltipleestricta / no estrictaselectiva / no selectivade implementación / de interfaz

FiguraCerrada

Polígono Elipse

CírculoCuadriláteroPentágono

RomboRectángulo


Herencia

Exception

IOException

Padres / Ascendiente / Superclases

Hijos / Descendientes / Subclases

• Una subclase hereda (dispone de) los atributos y métodos de la superclase, y puede añadir otros nuevos.

• La subclase puede modificar el comportamiento heredado (p. e., redefiniendo algún método heredado) .

• La herencia es transitiva.• Los objetos de una clase que hereda de

otra pueden verse como objetos de esta última (polimorfismo de datos).


Javaclass 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(){ masa = m; };

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

void masa(double);double masa();double atraccion(Particula&);

};

“Par

ticul

a.hp

p”


#include “Partic.hpp”

void Particula::masa(double m) { masa = m;

}

double Particula::masa() { return masa;

}

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

}

C++“P

artic

ula.

cpp”


class Particulainherits Puntocreation 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)

endend Particula;

Eiffel


Punto subclass: #ParticulainstanceVariableNames: ‘ masa ’classVariableNames: "poolDictionaries: "

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

masa^masa

masa: unNummasa := unNum

atraccion: unaPart^ G * masa * (unaPart masa) /

((self distancia: unaPart) squared)

Smalltalk


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.

• 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.

Polígono

perímetro( ): double

Cuadrado

perímetro( ): double

lado: float

Suma de distancias entre puntos consecutivos

Resultado = 4 * lado


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.

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

Pensionista TrabajadorActivo

MedioPensionista


Herencia múltiple: ambigüedades

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

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

elAbuelo: MedioPensionista

Pensionista

pensión

calcularIRPF( ): short

TrabajadorActivo

salario

calcularIRPF( ): short

calcularIRPF( )


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:

Pensionista TrabajadorActivo

MedioPensionista

Personanombre:String

pensión: Float salario: Float

elAbuelo: MedioPensionistaPensionista::nombreTrabajadorActivo::nombrepensiónsalario

¡!


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 virtualAmbigü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 variablesLos receptores de mensajesLos parámetros de mensajesLos resultados de mensajes.

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


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

Java

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

(Punto)x = 0y = 0

part pto

pto = part; // Asignación correctapart = pto; // Asignación incorrectapart = (Partícula)pto; // Peligroso

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


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

C++

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

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

(Punto)x = 0y = 0

ppart ppto

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


Polígono

Cuadrado

perímetro{^...}

perímetro{^4*lado}

:Polígono

:Cuadrado

obj : Polígono

perímetro?

• 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 formaexplícita las funciones que han de resolverse dinámicamente: funciones virtual.

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.


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 = new PuntoAcotado(eI,eD);

PuntoAcotadox= 0y= 0

pacPuntoAcotadox = 1y = 1

pto

Punto pto;

Java

pto = pac;

pto.trasladar(3,3);

trasladar(3,3)VINCULACIÓN

DINÁMICA

class Punto {private double x, y; public Punto(){…}…public voidtrasladar(double a, double b)

{x += a; y += b; }public double distancia(Punto p){…}

};

Punto eI = new Punto(0,0);

Punto eD = new Punto(2,2);


class PuntoAcotado: public Punto {Punto esquinaI,esquinaD;

public:PuntoAcotado(Punto eI, Punto eD);double ancho();double alto();

};void trasladar(double a, double b);

C++

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);

}


C++

ppto

Punto *ppto;

PuntoAcotado *ppart = new PuntoAcotado(eI,eD);


ppac

ppto = ppac;

ppto->trasladar(3,3);

trasladar(3,3)PuntoAcotadox= 3y= 3

VINCULACIÓN

ESTÁTICA

class Punto {double x, y;

public:Punto();Punto(double a, double b);~Punto();…void trasladar(double a, double b);double distancia(Punto& pp);

};

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

Punto *eD = new Punto(2,2);


C++

ppto

Punto *ppto;

PuntoAcotado *ppart = new PuntoAcotado(eI,eD);


ppac

ppto = ppac;

ppto->trasladar(3,3);

trasladar(3,3)PuntoAcotadox= 1y= 1

VINCULACIÓN

DINÁMICA

class Punto {float x, y;

public:Punto();Punto(double a, double b);~Punto();…void trasladar(double a, double b);double distancia(Punto& pp);

};

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

Punto *eD = new Punto(2,2);

virtual


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)

Punto

x, y: double

trasladar(a, b)distancia(pto)

Partícula

masa: double

atracción(part)

Segmento

trasladar(a, b)longitud()

origen

extremo


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 implementarfunciones abstractas en Javafunciones virtuales puras en C++rutinas “deferred” en Eiffelmé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++


= new Polígono();

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

Java

CLASE ABSTRACTA


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

apilar(TipoBásico): voiddesapilar(): voidesVacía: boolean

TipoBásico

cima: TipoBásico

Pila<Polígono>

Pila<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 datosMovilidadEtc.

Introducción a la Programación Orientada a Objetosjmmb/lto/LTO-Tema1.pdf · Orientada a Objetos...

Documents

Transcript of Introducción a la Programación Orientada a Objetosjmmb/lto/LTO-Tema1.pdf · Orientada a Objetos...