El Modelo Objeto
• La Evolución del Modelo Objeto
•
•
Lenguajes de Primera Generación (1954 - 1958 ) :
– Todos eran de expresiones Matemáticas.
• Fortran I, ALGOL 58 ...
Lenguajes de Segunda Generación (1959 - 1961 ) :
– Fortran II, Subrutinas y compilación separada.
– ALGOL 60, Bloques de estructuras, Tipos de Datos.
•
•
•
Lenguajes de Tercera Generación ( 1962 - 1970 ) :
– PL/1, Fortran + Algol + Cobol
– Pascal, Sucesor simple
Lenguajes de transición ( 1970 - 1980 )
– Aparecen gran cantidad de lenguajes pero pocos perduran.
Pero es a finales de esta época cuando empieza a coger gran importancia la programación
orientada a objeto para grandes aplicaciones.
03/10/2015
1
El Modelo Objeto
•
Programación Orientada a Objetos:
–
–
–
–
La programación Orientada a Objeto es un método de implementación en la cual los programas
son organizados como cooperación de colecciones de objetos, cada uno de los cuales representa
una instancia de alguna clase, y cuyas clases son todas miembros de una jerarquía de clases
unidas por relaciones de herencia.
Se Soportan objetos que son abstracciones con una interface de operaciones y estado local
oculto.
Los objetos tienen asociado un tipo (clase).
Estos tipos (clases) pueden heredar atributos de supertipos.
03/10/2015
2
El Modelo Objeto
•
Diseño Orientado a Objeto
– El Diseño Orientado a Objeto es un método de diseño que incluye un proceso de
descomposición orientada a objeto y una notación capaz de representar tanto lógica
como físicamente un sistema bajo diseño y ofrecer para ambos casos modelos
estáticos y dinámicos.
– En esta definición hay 2 partes importantes:
• 1.- El Diseño orientado a objeto nos guía hacia una descomposición orientada
a objeto y
• 2.- utiliza diferente notación para expresar los diferentes diseños tanto lógicos
como físicos de un sistema, además de los aspectos estáticos y dinámicos del
diseño.
•
Análisis Orientado a Objeto
– El análisis orientado a objeto es un método de análisis que examina los requisitos
desde la perspectiva de las clases y los objetos encontrados en el vocabulario del
dominio del problema.
03/10/2015
3
ELEMENTOS DEL MODELO OBJETO
•
Tipos de paradigmas de la programación:
– Cinco estilos principales de programación:
• Orientado al Procedimiento: Algoritmos
• Orientado a Objeto: Clases y Objetos
• Orientado a la lógica: Objetivos, generalmente expresados como cálculo de
predicados
• Orientado a la Regla: Reglas tipo If - Then
• Orientado a restricciones: Relaciones Invariantes
•
•
•
•
No hay un estilo de programación que sea mejor para todos los tipos de aplicaciones.
La experiencia dice que el Orientado a Objeto es el estilo más conveniente para un mayor
conjunto de aplicaciones.
Cada uno de estos estilos de programación está basado en su propio sistema conceptual.
En lo que se refiere a la orientación a objeto, su sistema conceptual es el Modelo Objeto.
03/10/2015
4
ELEMENTOS DEL MODELO OBJETO
•
Los cuatro principales elementos de este modelo son :
–
–
–
–
•
Abstracción
Encapsulación
Modularidad
Jerarquía
Pero también existen otros tres elementos de menor importancia pero
que también forman parte del modelo:
– Tipado
– Concurrencia
– Persistencia
03/10/2015
5
ELEMENTOS DEL MODELO OBJETO
•
ABSTRACCIÓN
–
La abstracción es uno de los mecanismos fundamentales con los que los humanos conseguimos
entender la complejidad. La Abstracción denota las características esenciales de un objeto que
le distinguen de todos los demás. Estas características proveen unos límites conceptuales muy
claros y de acuerdo al punto de vista con que se ve al objeto. Existen también diferentes tipos
de abstracciones que son los siguientes:
– Abstracción de Entidad :
•
•
•
•
•
•
•
03/10/2015
Un objeto que representa un modelo útil de una entidad perteneciente al dominio del
problema o la solución.
Abstracción de Acción :
Un objeto que proporciona un conjunto de operaciones generalizadas, donde cada uno de
ellas realiza el mismo tipo de función.
Abstracción de Máquina Virtual :
Un objeto que agrupa conjuntamente operaciones que son, todas, utilizadas por algún
nivel superior de control, u operaciones que usen algún conjunto de operaciones de nivel
inferior .
Abstracción Coincidental :
Un objeto empaqueta un conjunto de operaciones que no tienen relación entre ellas.
6
ELEMENTOS DEL MODELO OBJETO
• Definiciones
• Cliente
– Un cliente es un objeto que usa los recursos de otro objeto
(servidor). Podemos caracterizar el comportamiento de un objeto
por considerar el servicio que da a los otros objetos, al igual que
las operaciones que realiza sobre los otros objetos.
– Protocolo
– Un protocolo denota la manera en la cual un objeto puede actuar
y reaccionar;
es así, la vista exterior estática y dinámica de la abstracción.
• Los términos operación, método, y Función Miembro
evolucionaron de tres diferentes culturas de programación.
03/10/2015
7
ELEMENTOS DEL MODELO OBJETO
• ENCAPSULACIÓN
• La abstracción y la encapsulación son conceptos
complementarios: La abstracción se ocupa de la vista exterior
de un objeto, por otro lado, la encapsulación oculta los detalles
de la implementación (vista interna) a los clientes.
• La encapsulación es el proceso de ocultar todos los
detalles de un objeto que no contribuyen a sus
características escenciales.
03/10/2015
8
ELEMENTOS DEL MODELO OBJETO
• MODULARIDAD
•
– “ El hecho de particionar un programa en componentes individuales puede
reducir la complejidad en algunos grados. “. El uso de módulos es esencial
para ayudar al manejo de complejidad. La modularización consiste en
dividir un programa en módulos que pueden ser compilados
separadamente, pero los cuales tienen conexiones con los otros módulos.
La mayor parte de los lenguajes que soportan los módulos como un
concepto separado también distinguen entre la interface de un módulo y su
implementación. El coste de recompilar un módulo es relativamente
pequeño, sin embargo, el coste de recompilar la interface de un módulo es
relativamente alto.
La modularidad es la propiedad de un sistema que ha sido
descompuesto en un conjunto de módulos más pequeños,
cohesivos y débilmente acoplados.
03/10/2015
9
ELEMENTOS DEL MODELO OBJETO
• JERARQUÍAS
•
La Abstracción es un buen método, pero excepto en las aplicaciones triviales,
siempre encontraremos mas tipos de abstracción distintos de los que podemos
entender a la vez.
•
Un conjunto de abstracciones a menudo forma una jerarquía.
–
–
•
Esto permite que algunos objetos se construyan a partir de otros objetos.
Por ejemplo, la clase animales se divide en mamíferos, anfibios, insectos,
pájaros, ...
La jerarquía es un rango u orden de abstracciones.
– Los dos tipos de jerarquías más importantes que hay son:
– La estructura de clase y la estructura de objeto.
– En C++, la clase original se denomina clase base; las clases que se definen a partir
de esta se denominan clases derivadas.
– Las clases derivadas pueden heredar tanto código como datos de la clase base
además de poder añadir ellas su propio código y sus variables.
03/10/2015
10
ELEMENTOS DEL MODELO OBJETO
• TIPADO
•
•
•
•
•
•
•
El concepto de tipo, deriva directamente de la teoría de los tipos de datos
abstractos.
Utilizar Tipos significa especificar de forma rígida la clase de un objeto,
así, objetos de diferentes tipos no podrían ser intercambiados, o a lo
sumo, estos podrían ser intercambiados de unas maneras muy
restrictivas.
Existe un gran número de ventajas si se utiliza un lenguaje tipado.
Sin el chequeo de tipos, en la mayoría de lenguajes, un programa puede fallar
de forma “misteriosa” en tiempo de ejecución.
En la mayoría de sistemas, el proceso de edición-compilación-debugging es tan
tedioso que la detección de la mayor cantidad de errores posibles al principio es
indispensable.
La declaración de tipos ayuda a la documentación de los programas.
La mayoría de los compiladores pueden generar código más eficiente si se
declaran los tipos.
03/10/2015
11
ELEMENTOS DEL MODELO OBJETO
• CONCURRENCIA
•
En ciertos tipos de problemas, un sistema automático puede tener necesidad de
gestionar diferentes eventos simultáneamente. Para ello es natural considerar el
uso de un sistema distribuido (diferentes CPU’s) con capacidad de
multiproceso. Sin embargo en sistemas con una sola CPU, solamente podemos
generar una ilusión de concurrencia.
•
Podemos distinguir 2 tipos de concurrencia:
–
–
•
Procesos heavyweight que son manejados de manera independiente por el sistema operativo y
que poseen sus propios espacios de direcciones.
Procesos lightweight, son procesos que comparten el mismo espacio de direcciones que otros
procesos.
La concurrencia es la propiedad que distingue a un objeto activo de
otro inactivo.
03/10/2015
12
ELEMENTOS DEL MODELO OBJETO
• PERSISTENCIA
• La persistencia es la propiedad de un objeto a través
de la cual su existencia es permanente en el tiempo
(por ejemplo, un objeto existe después de que su
creador deje de existir) y / o espacio (la localización
de un objeto se mueve de la dirección de la que fue
creado).
03/10/2015
13
APLICANDO EL MODELO OBJECTO
• El modelo objeto es fundamentalmente diferente de los modelos
más tradicionales de análisis estructurados.
• Hay 4 razones principales por las que es preferible la utilización
del modelo objeto:
– El modelo objeto nos ayuda a explotar el poder expresivo de todos los
lenguajes basados en objeto y orientados a objeto.
– La utilización del modelo objeto favorece la reutilización no solo del
software sino de diseños completos.
– Permite construir sistemas basados en formas intermedias estables, más
flexibles a cambios.
– El modelo objeto se asimila a la forma en que trabaja el conocimiento
humano.
03/10/2015
14
OBJETOS
•
Qué es un Objeto:
– algo tangible, que se puede entender, que llama la atención
– tiene límites bien definidos
Un objeto tiene un estado, comportamiento e identidad; la
estructura y el comportamiento de objetos similares se definen en
clases comunes; los términos instancia y objeto son equivalentes.
El estado de un objeto incluye todas las propiedades del objeto
(normalmente estáticas) junto a los valores actuales de cada una de
esas propiedades (normalmente dinámicos). Representa los resultados
acumulados de su comportamiento.
Identidad: Es la propiedad de un objeto que le hace distinguible del
resto de objetos.
03/10/2015
15
OBJETOS
•
•
Ejemplo:
– Si consideramos la siguiente
estructura:
struct PersonnelRecord
{
char name[100 ];
int socialSecurityNumber;
char departament[10];
float salary;
};
Cada parte de esta estructura
delimita una propiedad particular
de nuestra abstracción de
PersonnelRecord.
03/10/2015
•
•
•
•
Esta declaración nos define una
clase, no un objeto porque no se
representa
una
instancia
específica. Si deseamos declarar
un objeto de esta clase lo que
debemos hacer es:
PersonnelRecord Toni, Karem;
De esta forma declaramos dos
objetos diferentes que se colocan
en sendos espacios de memoria
diferentes.
Ninguno
de
estos
objetos
comparte espacio con ninguno de
los otros, pero las propiedades
son las mismas.
16
OBJETOS
• Comportamiento:
– El comportamiento de un objeto define como un objeto actúa y
responde, es decir, en términos de cambios de estados, y paso de
mensajes.
– En la mayoría de los lenguajes de programación Orientados a
Objeto, las operaciones que los clientes pueden hacer sobre los
objetos se definen como métodos, los cuales son parte de la
declaración de la clase.
– C++ utiliza el término Función Miembro para definir ese
concepto.
03/10/2015
17
OBJETOS
•
•
Operaciones: Una operación define un servicio que una clase ofrece a sus
clientes, en la práctica podemos clasificar en 5 categorías los servicios que
puede ofrecernos un objeto.
Estos servicios son los siguientes :
– Modificador: Son operaciones que alteran el estado de un objeto.
– Selector: Una operación que accede al estado de un objeto, pero no lo
altera.
– Iterador: Un objeto que permite el acceso a todas las partes de un objeto
en un orden bien definido.
Pero los dos servicios más comunes son los siguientes.
• Constructores: Una operación que crea un objeto y/o inicializa su estado.
• Destructores: Una operación que libera los recursos utilizados en la
representación del estado de un objeto y/o destruye al propio objeto.
03/10/2015
18
OBJETOS
• Roles y responsabilidades:
– Colectivamente, todos los métodos y sub-programas de un objeto
en particular componen su protocolo.
– El protocolo define el comportamiento permitido de un objeto
• Es el “contrato” entre el objeto y sus clientes
– El estado y comportamiento de un objeto colectivamente define los
roles que un objeto puede jugar en el mundo, lo cual, a su vez,
establece las responsabilidades de la abstracción.
– Responsabilidades de un objeto: conocimiento almacenado y
acciones que puede realizar
03/10/2015
19
OBJETOS
• Copia, Asignación e Igualdad:
– void highlight ( DisplayItem& i);
– void drag (DisplayItem i);
•
•
// Peligro !!!
Invocando a la primera función con el argumento item1 se crea un
alias:
El parámetro formal i denota una referencia a los objetos designados
por el parámetro, y desde item1 y i se nombrará al mismo objeto en
tiempo de ejecución. Por otra parte , invocando a la segunda función
con el argumento item1 hacemos una copia del parámetro actual, de
esta forma, no existe alias: i denota a un objeto completamente
diferente a item1(aunque con el mismo estado).
03/10/2015
20
OBJETOS
• Copia, Asignación e Igualdad
• En algunas situaciones, sin embargo, es posible controlar la
semántica de copia. En particular, se puede declarar un
constructor de copia en las declaraciones de la clase:
– DisplayItem ( const DisplayItem& );
• Un constructor de copia puede ser invocado explícita o
implicitamente.
• Se puede omitir el constructor de copia solamente cuando haya
abstracciones simples, con valores primitivos; en todos los otros
casos se debe codificar.
03/10/2015
21
OBJETOS
• Copia, Asignación e Igualdad
– virtual DisplayItem& operator=(const DisplayItem&);
– virtual bool operator==(const DisplayItem&) const;
– bool operator!=(const DisplayItem&) const;
03/10/2015
22
RELACIONES ENTRE OBJETOS
• Tipos de Relaciones:
– Podemos encontrar que existen dos tipos de
jerarquías de objetos que pueden resultar
interesantes en análisis y diseño Orientados a
Objetos:
• LINKS
• AGREGACIONES
03/10/2015
23
RELACIONES ENTRE OBJETOS
LINK
• LINKS: ( Enlace ) El término link deriva de Rumbaugh, que
define esto como una “ Conexión física o conceptual entre dos
objetos“. Como participante de un link, un objeto podría jugar
alguno de estos roles:
– Actor: Un objeto que puede actuar sobre otros objetos
pero nunca se actúa sobre él. En algunos contextos, el
término de objeto activo y actor son intercambiables.
– Server: Un objeto que nunca opera sobre otros objetos,
solamente operan sobre él.
– Agent: Estos son los objetos que operan sobre otros y
que a su vez se puede operar sobre ellos.
03/10/2015
24
RELACIONES ENTRE OBJETOS
LINK
• EJEMPLO
typedef unsigned int Minute;
class TemperatureRamp {
public:
TemperatureRamp();
virtual ~ TemperatureRamp();
virtual void clear();
virtual void bind(Temperature, Minute);
Temperature temperatureAt(Minute);
protected:
…..
};
03/10/2015
Temperature
T
t1
t2
Time
25
RELACIONES ENTRE OBJETOS
LINK
• EJEMPLO:
typedef unsigned int Location;
class TemperatureController{
public:
TemperatureController(Location);
~ TemperatureController();
void process(TemperatureRamp&);
Minute schedule(const TemperatureRamp&) const;
//determina el tiempo óptimo en el que se podrá procesar la rampa
private:
……
};
03/10/2015
26
RELACIONES ENTRE OBJETOS
LINK
• EJEMPLO
TemperatureRamp growingRamp;
temperatureController rampController(7);
growingRamp.bind(250,60);
growingRamp.bind(150,180);
rampController.process(growingRamp);
• rampController es un agente que realiza el control de temp.
• utiliza el objeto growingRamp como server
• el link (enlace) se ve en el hecho de que el controlador usa como
argumento de sus operaciones al objeto growingRamp
03/10/2015
27
RELACIONES ENTRE OBJETOS
LINK
• Visibilidad: Consideremos dos objetos, A y B, los cuales
poseen un link entre ambos. Para poder enviar desde A un
mensaje B, B debe ser visible a A de alguna manera.
• Estas formas son las siguientes:
– El objeto suministrador es global al cliente.
– El objeto suministrador es un parámetro de alguna
operación del cliente.
– El objeto suministrador es parte del objeto cliente.
– El objeto suministrador está localmente declarado en
alguna operación del cliente.
03/10/2015
28
RELACIONES ENTRE OBJETOS
LINK
• Sincronización: Cuando un objeto pasa un mensaje a otro
a través de un link, se dice que los dos objetos están
sincronizados.
Existen tres tipos de sincronización:
– Secuencial: La semántica del objeto pasivo está garantizada
solamente en presencia de un único objeto activo a la vez.
– Protegido: La semántica del objeto pasivo está garantizada frente
a la presencia de múltiples hebras de control, pero los clientes
activos deben colaborar para conseguir la exclusión mutua.
– Síncronos: La semántica del objeto pasivo está garantizada frente
a la presencia de múltiples hebras de control, y el suministrador
garantiza la exclusión mutua.
03/10/2015
29
RELACIONES ENTRE OBJETOS
Agregación
• Los links nos denotan relaciones punto a punto o
relaciones de Cliente / Servidor,
• La agregación nos denota una jerarquía de TodoParte, con la posibilidad de poder ir desde el todo
hacia las partes. Podríamos decir que la agregación es
un tipo especial de asociación.
• La agregación puede o no indicarnos un contenido
físico. Avión, accionista.
03/10/2015
30
RELACIONES ENTRE OBJETOS
Agregación
class TemperatureController{
public:
TemperatureController(Location L):h(L){}
~ TemperatureController();
void process(TemperatureRamp&);
Minute schedule(const TemperatureRamp&) const;
//tiempo óptimo en el que se podrá procesar la rampa
private:
Heater
h;
…….
};
03/10/2015
31
RELACIONES ENTRE OBJETOS
Link / Agregación
TemperatureRamp growingRamp;
temperatureController rampController(7);
• En la figura se ve que rampController tiene un link con growingRamp
• h es una parte (agregación) de rampController.
• dado un container es posible encontrar sus partes
• dada una parte no siempre se puede conocer su container
growingRamp
• la agregación encapsula
temperatureAT()
• el link proporciona enlaces débiles
• la agregación tiene un link implicito
entre container y partes.
rampControler
h:Heater
03/10/2015
32
La Naturaleza de las Clases
• QUE ES Y QUE NO ES UNA CLASE ?
•
•
•
•
Los conceptos de clase y de objeto son a menudo confundidos. No se puede
hablar de objeto sin referirnos a lo que es una clase, sin embargo existen
importantes diferencias entre lo que es cada uno de estos dos términos.
Podemos considerar a un objeto como una entidad concreta que existe en un
tiempo y un espacio, en cambio, una clase representa solamente una
abstracción, la “ esencia “ de un objeto.
Una clase es un conjunto de objetos que comparten un comportamiento y
una estructura comunes. Un objeto es una simple instancia de una clase.
Que no es una clase ? Un objeto no es una clase, en cambio, una clase si que
puede ser un objeto. Los objetos que no comparten su estructura y su
comportamiento no se pueden agrupar en una clase porque, por definición,
ellos no están relacionados excepto por el hecho de que son objetos.
También es importante notar que una clase es necesaria pero no suficiente
como vehículo de descomposición (“fat interfaces”).
03/10/2015
33
CLASES
•
•
•
•
•
INTERFACE E IMPLEMENTACIÓN
Un objeto individual es una entidad concreta que desempeña algunos
roles dentro de un sistema complejo,
La clase captura la estructura y el comportamiento común de todos los
objetos relacionados.
– Este hecho, visto desde el punto de vista de la programación, nos permite
diferenciar entre lo que son vistas externas de la clase y vistas internas.
La interface de una clase, nos muestra todas las características de la
clase y nos oculta toda su estructura interna (implementación).
Podemos encontrar 3 tipos diferentes de interfaces:
– Publica: Una declaración es accesible desde todos los clientes.
– Protegida: La declaración es accesible desde la propia clase, las subclases
de esta propia clase y desde las clases amigas “ friend “.
– Private: La declaración es accesible desde la propia clase y desde las
clases amigas “ friend “.
03/10/2015
34
LAS RELACIONES ENTRE CLASES
•
•
Las clases y los objetos no existen como entes aislados. Existen toda
una serie de relaciones entre los diferentes tipos de clase y objetos.
Estas relaciones se establecen por una de estas dos razones:
– Una relación entre clases nos puede indicar algún tipo de compartición.
– Una relación entre clases nos puede indicar algún tipo de conexión
semántica.
•
En general,hay tres tipos básicos de relaciones diferentes entre clases:
•
•
•
Generalización / Especialización
Todo / Parte
Asociación
03/10/2015
35
LAS RELACIONES ENTRE CLASES
Generalización / Especialización
– Representa una jerarquía de clases, es decir, clases derivadas de una clase
más general. Su notación es “ A es un/una B“
•
Todo / Parte
– Se denota como “ A es parte de B “. Indica que los objetos de una
determinada clase, forman parte de algún otro objeto de otra clase. Es
decir, que mientras la relación generalización / especialización indica una
especialización ( herencia de propiedades ), la relación Todo / Parte
indica que una clase contiene un conjunto de objetos de otra
•
Asociación
– Denota la dependencia semántica entre tipos de clase no relacionadas.
03/10/2015
36
LAS RELACIONES ENTRE CLASES
•
La mayoría de los lenguajes orientados a objetos proporcionan soporte
directo para combinaciones de las siguientes relaciones:
• Asociación
• Herencia
• Agregación
• Uso
• Instanciación
• Metaclases
03/10/2015
37
LAS RELACIONES ENTRE CLASES
Asociación
• Es la más general pero también es la mas débil semánticamente.
Venta
Producto
N
1
Última
Prod.
Vendido
Venta
• Como se muestra en la figura anterior, podemos mostrar una
simple asociación entre estas dos clases, la clase producto
denota los productos vendidos como parte de una venta. Y por
implicación, esta asociación sugiere una relación bidireccional.
03/10/2015
38
LAS RELACIONES ENTRE CLASES
Asociación
class Sale;
class Product {
public:
.....
protected:
Sale *lastSale;
};
class Product;
class Sale {
public:
.....
protected:
Product** productSold;
};
Una asociación solamente denota una dependencia semántica.
•Existen cero o más instancias de una clase producto, y por cada producto,
hay una venta. Esta multiplicidad denota la cardinalidad de la asociación.
En la práctica, hay tres tipos comunes de cardinalidad.
•
Uno a Uno, Uno a Muchos, Muchos a Muchos.
03/10/2015
39
LAS RELACIONES ENTRE CLASES
HERENCIA
Telemetry
Data
Electrical
Data
Sensor
Data
Propulsion
Data
Camera
Data
03/10/2015
Radiation
Data
40
LAS RELACIONES ENTRE CLASES
HERENCIA
class Time;
struct ElectricalData {
Time timeStamp;
int Id;
float fuelCell1Voltage, fuelCell2Voltage;
float fuelCell1Amperes, fuelCell2Amperes;
float currentPower;
};
• Problema: no esta encapsulada.
• Solución: la declaración de otra clase que nos proteja los datos
que no queremos que se modifiquen.
03/10/2015
41
LAS RELACIONES ENTRE CLASES
HERENCIA
class TelemetryData {
public:
TelemetryData();
virtual ~TelemetryData();
virtual void transmit();
Time currentTime() const;
protected:
int id;
Time timeStamp;
};
03/10/2015
• Esta declaración de clase
posee un constructor y un
destructor virtual.
• Los objetos ID, timeStamp
están
un
poco
más
encapsulados, y por esto
son accesibles solamente
por su propia clase y por
todas sus subclases.
42
LAS RELACIONES ENTRE CLASES
HERENCIA
class ElectricaData: public TelemetryData {
public:
ElectricaData ( float v1, float v2, float a1, float a2);
virtual ~ ElectricaData();
virtual void transmit();
float currentPower() const;
protected:
float fuelCell1Voltage, fuelCell2Voltage;
float fuelCell1Amperes, fuelCell2Amperes;
};
• Hereda la estructura y el comportamiento de la clase TelemetryData.
Agrega a su estructura los cuatro atributos protegidos. Redefine su
comportamiento
(transmit())
y
agrega
mas
funcionalidad
(currentPower).
03/10/2015
43
LAS RELACIONES ENTRE CLASES
HERENCIA
• SIMPLE / MÚLTIPLE:
• La herencia es una relación entre clases
donde una clase comparte la estructura y/o
comportamiento definido en una (simple) o
más clases (múltiple).
03/10/2015
44
POLIMORFISMO SIMPLE
El mecanismo del polimorfismo es la propiedad por la cual objetos
que pertenecen a clases diferentes pueden responder al mismo
mensaje de formas diferentes.
• Función miembro transmit de la • La misma función miembro
claseTelemetryData:
para la clase ElectricaData:
void ElectricaData::transmit()
void TelemetryData::transmit()
{
{
TelemetryData::transmit();
// Transmit de ID
// transm. de Voltajes
// Transmit de timeStamp
// transm. de Amperios
}
}
•
03/10/2015
Invocamos la función de la
SuperClase TelemetryData::transmit
(transmite
los
datos
ID
y
timeStamp) y luego enviamos los
datos particulares de la Subclase
ElectricalData.
45
POLIMORFISMO SIMPLE
TelemetryData telemetry;
ElectricalData electrical (5.0, -5.0, 3.0, 7.0);
•
En el primero de los casos,
transmitimos un stream de bits
consistente solo en un id y en
un timeStamp.
•
En el segundo caso, enviamos
otro stream de bits , pero que
en este caso incluirían un id, un
timeStamp y además, otros 4
valores float.
y la siguiente función no miembro:
void
transmitFreshData (TelemetryData& d,
const Time& t)
{
if ( d.currentTime() >= t )
d.transmit ();
}
•
ejecutamos:
trasmitFreshData ( telemetry, Time (60));
trasmitFreshData (electrical, Time (120));
03/10/2015
46
POLIMORFISMO MÚLTIPLE
• Ejemplo: supongamos que se dispone de las clases cuadrado,
triángulo y círculo, cuyos objetos de estas clases pueden
comprender un mensaje dibujar() que dibuja la correspondiente
figura en la pantalla. Sin embargo, la respuesta al mensaje
dibujar será diferente para cada uno de los objetos círculo,
cuadrado y triángulo.
• Si a dibujar le agregamos un parámetro: dibujar(Device& d),
donde Device es base de una jerarquía, tendremos el
polimorfismo múltiple.
03/10/2015
47
HERENCIA Y TIPADO
• Consideremos de nuevo la redefinición del miembro
transmit:
void ElectricaData::transmit()
{
TelemetryData::transmit();
// transmit de Voltages
// transmit de Amperios
}
• La mayoría de los lenguajes orientados a objeto, permite que la
implementación de un método de una subclase invoque
directamente un método definido en una Superclase.
03/10/2015
48
HERENCIA Y TIPADO
• El paralelismo entre el tipado y la herencia se puede observar
cuando vemos la jerarquía de generalización / especialización
creada a través de la herencia como el medio de capturar la
conexión semántica entre abstracciones:
TelemetryData telemetry;
ElectricalData electrical (5.0, -5.0, 3.0, 7.0);
telemetry = electrical; //electrical es un subtipo de telemetry: peligro
electrical=telemetry;
//telemetry
no
es
un
subtipo
de
electrical:ERROR
• Muchos de los lenguajes con tipado fuerte normalmente permiten
conversiones de valores entre diferentes objetos, pero en general
solo si existe algún tipo de relación de Superclase / Subclase
entre ambos.
03/10/2015
49
HERENCIA Y TIPADO
class InternalElectricalData : private ElectricalData {
public:
InternalElectricalData ( float v1, float v2, float a1, float a2 );
virtual ~ InternalElectricalData();
ElectricalData::currentPower;
};
• En esta declaración, los métodos como transmit no son visibles
para los clientes de esta clase, porque ElectricaData está
declarada como SuperClase privada. El hecho de que
InternalElectricalData no sea subtipo de ElectricalData, también
significa que no podremos asignar instancias de
InternalElectricalData a objetos de la SuperClase, como
podríamos hacer con clases que usan la herencia pública de la
SuperClase. currentPower es visible porque está explicito.
03/10/2015
50
HERENCIA MÚLTIPLE
• Con la herencia múltiple, cada subclase posee más de una
SuperClase.
• La implementación en C++ de la herencia múltiple:
class A { .... };
class B { .... };
class C { .... };
class D : public A, virtual B, protected C .…
protected es equivalente a private excepto que la parte protegida
de la superclase es accesible desde subclases de niveles
inferiores
03/10/2015
51
AGREGACIÓN
•
La relación de agregación entre clases está directamente relacionada
con la agregación entre los objetos de esas clases.
class TemperatureController {
public:
Temperature
TemperatureController ( Location );
Controller
~ TemperatureController();
void process ( const TemperatureRamp& );
private:
Heater
Heater h;
};
• La Agregación establece una dirección para la relación Todo / Parte.
Heater es una parte del objeto TemperatureController pero lo contrario
no es cierto.
03/10/2015
52
Uso
• Las relaciones de uso entre clases son similares a los enlaces
punto a punto con las correspondientes instancias de estas
clases.
• Mientras una asociación denota una conexión semántica
bidireccional, una relación de uso es un posible refinamiento de
una asociación, con lo que podemos definir qué abstracción es
el cliente y qué abstracción es el servidor de un determinado
servicio. Un ejemplo
Temperature
Controller
Temperature
Ramp
Relación de Uso
03/10/2015
53
INSTANCIACIÓN
•
Supongamos la declaración de la •
clase Queue.
template <class T>
class Queue {
public:
Queue();
•
virtual ~Queue();
virtual void append (const T &);
virtual void pop();
...
};
Queue < int > intQueue;
Queue<DisplayItem*>intemQueue;
03/10/2015
intQueue e itemQueue son
instancias de diferentes clases,
y no están unidas por una
Super Clase, aunque ambas
derivan de la misma clase
parametrizada.
Existen cuatro tipos básicos de
instanciación:
– Utilizando Macros.
–
–
–
Utilizar la aproximación que realiza
Smalltalk (herencia y “late binding”)
Utilizar la aproximación propuesta
Object Pascal (anterior + tipo)
Utilizar la aproximación propuesta
por CLU: un mecanismo directo
para la parametrización de clases
(patrones en C++ ).
54
METACLASES
• Hemos dicho que cada objeto es la instancia de alguna clase.
• Una METACLASE es una clase cuyas instancias son, a su vez,
clases.
• Aunque C++ no proporciona soporte explicito para MetaClases,
su semántica de constructor y destructor sirven al proposito de
la creación de operaciones de MetaClases.
• C++ también tiene facilidades para variables tipo clases y
operaciones de MetaClases.
– En C++ podemos declarar un objeto o una función miembro de tipo
static, significando esto que los miembros están compartidos por
todas las instancias de la clase.
03/10/2015
55
RELACIONES ENTRE CLASES Y
OBJETOS
• Las clases y los objetos están separados y a
la vez, íntimamente relacionados.
• Cada objeto es la instancia de alguna clase,
y cada clase puede tener, o no, instancias.
• Para las aplicaciones prácticas, las clases
son estáticas, por eso, su existencia,
semántica y relaciones están fijadas antes de
la ejecución del programa.
03/10/2015
56
CALIDAD DE LA ABSTRACCIÓN
• El diseño de clases y objetos es un proceso incremental e
iterativo. Exceptuando las declaraciones de clases triviales,
casi nunca podemos definir una clase correctamente desde el
principio.
• Podemos sugerir una serie de métricas que nos ayuden a
definir un posible “ valor “ para saber que cantidad de
abstracción posee una aplicación:
• Acoplamiento
–
–
–
–
Cohesión
Suficiencia
Completitud
Primitividad ( “ primitiveness “ )
03/10/2015
57
Descargar

El Modelo Objecto