Programaci´n Orientada a Objetos o

Laura M. Castro Souto Primer Cuatrimestre Curso 2000/2001

2

´ Indice de cuadros
4.1. Tabla resumen de la evoluci´n de la Orientaci´n a Objetos . . . . . . . . . 34 o o

3

4

´ INDICE DE CUADROS

Cap´ ıtulo 1 Evoluci´n de los lenguajes de o programaci´n o
La programaci´n ha ido evolucionando desde sus or´ o ıgenes, donde los lenguajes eran de muy bajo nivel y las posibilidades reducidas, refin´ndose cada vez m´s hasta alcanzar a a el alto nivel y relativa sencillez actuales. Veremos a grandes rasgos c´mo se ha desarrollado este proceso. o

1.1.

Programaci´n no estructurada o

En sus primeros momentos, decimos que la programaci´n llevada a cabo en lenguajes o como el basic es no estructurada. Los programas eran una serie de l´ ıneas de c´digo con o saltos (instrucci´nes tipo goto) y en un unico bloque (sin posibilidad de subrutinas; o ´ ´ basic cuenta unicamente con la instrucci´n gosub <direccion>). ´ o

1.2.

Programaci´n procedimental o

Con la aparici´n de lenguajes como Pascal, surge la posibilidad del empleo de subrutio nas (funciones y procedimientos), lo que da nombre a esta “etapa” en que la programaci´n o se dice procedimental.

1.3.

Programaci´n estructurada o

La necesidad de dar claridad y legibilidad al c´digo provoca que se reconozcan una serie o de principios o reglas a la hora de estructurar un programa. Surge as´ la programaci´n ı o estructurada, cuyas directivas son: Estructura jer´rquica top-down. a Dise˜o modular. n Salidas y entradas claramente definidas. ´ Unico punto de entrada y unico punto de salida (tambi´n aplicable a funciones). ´ e Constructores de programaci´n estructurada: secuencia, selecci´n, iteraci´n y llao o o madas a procedimientos. 5

pod´ trabajar simult´neamente los diferentes integrantes de un grupo ´ deparıan a o tamento. Son los otros dos los que o marcan la diferencia. ´ ◦ Es posible crear m´ltiples instancias del tipo (algo que no era posible en programau ci´n modular).4. o 1. propugıa o nada por la programaci´n estructurada y el llamado dise˜ o mediante refinamiento o n progresivo. sin embargo. Se afronta el problema desde la “cima” y se va analizando de forma que se delimitan sucesiva y claramente las partes y funciones que realizar´n cada una de las a cuales. esta forma de programar.6.O. compuestos de l´ o o ıneas y l´ ıneas de c´digo en secuencia sin interrupci´n en diferentes m´dulos. por o o o ejemplo. Programaci´n modular o El siguiente paso consisti´ en la divisi´n de los largos programas. ejemplificaci´n o conn ıa o creci´n o 2 1 . hasta llegar a las m´s sencillas. o 1. ◦ El interfaz es el unico mecanismo de acceso a la estructura del TAD. Es decir. o El segundo y tercer puntos son comunes a los m´dulos. a la relaci´n que existe entre un objeto y la clase a la que pertenece (la clase de la que es o una instancia 2 . en los que. Es el paso previo a la orientaci´n a objetos.6 ´ ´ CAP´ ITULO 1. EVOLUCION DE LOS LENGUAJES DE PROGRAMACION Existe una analog´ entre este modo programaci´n. La filosof´ consiste en que creamos nuevos tipos y los usamos como si fuesen predefiıa nidos. deber´ usarse ejemplo.O. TADs Los Tipos Abstractos de Datos cuentan con una serie de caracter´ ısticas que exponemos a continuaci´n: o ◦ Exportan una definici´n de tipo. a Una clase es un TAD con una caracter´ ıstica a˜adida: permite la herencia. Realmente la palabra instancia no existe en espa˜ol.) es an´loga a la que hay entre una variable y el tipo del que es declarada. no permiten la instanciaci´n ni la exportaci´n de tipos.5. Los m´dulos. a a 1. directamente implementables de una manera f´cil. n clase = TAD + herencia simula 67 es el primer lenguaje que se puede considerar que soporta P. o o o Este iba a ser el siguiente pelda˜o en la escalera de la evoluci´n de los lenguajes de n o programaci´n. 1 Programaci´n Orientada a Objetos o Clases y objetos ser´n para nosotros conceptos similares a tipos y variables. o ◦ Hacen disponibles operaciones para manipular instancias del tipo (interfaz ).

Con la programaci´n orientada a objetos. que ine corpor´ los hoy tan populares applets. que no significa otra cosa que “granos de caf´”. en el que podemos tener diferentes ı o jerarqu´ y/o especializaciones. ıan Stroustrup. pero como el nombre ya estaba registrado. creado por Dyrabook. pues. Visual Basic). se hicieron apuestas sobre si el siguiente en la saga ser´ ’D’ (por e ıa orden alfab´tico) o ’P’ (por BCPL). e 4 3 .O. Los programas en P. El dise˜o en P. o El primer lenguaje totalmente orientado a objetos fue Smalltalk. habilitando al ıas mismo tiempo el polimorfismo. de los laboratorios Bell. El unico “fallo” que le fue achacado fue la falta de una interface WIMP3 . Existe una an´cdota sobre el nombre del lenguaje C++: C surge de la evoluc´ de B. manejan objetos que se comunican unos con otros mediante el intercambio de mensajes. en forma de subclases y superclases. con CLOS (Common Lisp Object o o e System) y muchos otros.7. Adem´s. Este lenguaje compila el c´digo fuente a a o un c´digo interno (Intermediate Language. C++. tienen la supremac´ en el campo de la RAD (Rapid ıa ıa Application Development). que o m´s tarde ser´a conocido como C++4 . el garbage collector y sobre todo su caracter´ o ıstica multiplataforma (bytecode). que se llamar´ C# (pronunciado C sharp). Windows Icons Mice Pointers. le pusieron lo que en ingl´s americano significa coloquialmente “caf´”.O. no es ya.O.O. ej. De aqu´ la gran importancia de una correcta ı identificaci´n de los objetos que vayan a participar en nuestro proyecto. o o o en cambio. un lenguaje e ıon construido a partir de BCPL (Basic cpl). Ahora mismo. No obstante. tambi´n Lisp.1. construy´ a partir de C un lenguaje C con clases. RESUMEN 7 Se define as´ un nuevo paradigma de programaci´n. similar al bytecode) y posteriormente a c´digo o o m´quina. ´ Parec´ que esta nueva concepci´n iba a cercarse alrededor de la IA y sus redes sem´ntiıa o a cas (los objetos parec´ adaptarse a sus directivas es parte de y es un) y marcos ıan (frames). El refinamiento progresivo usado hasta ahora era un refinamiento orientado al flujo de datos. Tambi´n se crearon lenguajes totalmente orientados a objetos como Java5 . que no favorece la reutilizaci´n de c´digo. 5 Los creadores de Java en principio le llamaron Oak (roble).: B. o Xerox PARC fue una de los primeros interesados en lo que se quer´ imponer como un ıa nuevo paradigma de programaci´n. top-down sino bottom-up. est´ a punto de ver la luz la versi´n que Microsoft ha hecho del lenguaje a o Java. Stroustrup evit´ el compromiso a˜adiendo el operador sucesivo a la e o n letra C. que se consideran s´lo o basados en objetos. Despu´s de tener un B y un C. pronto los dem´s lenguajes comenzaron a crear extensiones de s´ mismos a ı intentando incorporar las caracter´ ısticas que se defin´ fundamentales para la O. a su vez “hijo” de CPL (Combined Programming Languaje).O. a Hoy en d´ los lenguajes O. aunque algunos de los que se usan no cumplen todos los requisitos (p. sus componentes se e e a denominan Java Beans. o 1. Resumen El concepto de Orientaci´n a Objetos surge en torno a 1970 de mano de Alan Ray. a o Pero no s´lo C tuvo su extensi´n.7. en lugar de ir de lo n principal a lo espec´ ıfico se hace al contrario.O. las clases m´s generales pueden servirnos siempre para nuevos usos que las a requieran. con ejemplos como Delphi.

La caracter´ ıstica m´s com´nmente noa u soportada suele ser la posibilidad de herencia (fallo de VB). a a e proclamarse m´s r´pidos y eficientes. Eiffel. h´ ıbridos (C++. no a a es lo m´s adecuado. CLOS.O. a mientras que los llamados L. si se conocen aqu´llos de los que derivan.. que aunque por ser m´s abstractos son m´s f´cia a a les de manejar pero m´s lentos..O. . ). .O. Dentro de los Lenguajes Orientados a Objetos se hace una distinci´n entre L. Prolog++. . ) o o y a pesar de poder ser m´s f´ciles de aprender. o puros (como Smalltalk. EVOLUCION DE LOS LENGUAJES DE PROGRAMACION Diferencia entre lenguajes orientados a y basados en objetos Los Lenguajes Basados en Objetos poseen una sintaxis y una sem´ntica que pera miten la creaci´n de objetos.O.. a . Java. no permiten otra forma de hacer las cosas salvo la correcta.O. pero no poseen todas las caracter´ o ısticas necesarias para ser considerados plenamente orientados a objetos. ) mezclan la O.O. Object Pascal. . con otro paradigma (programaci´n estructurada / funcional / l´gica.8 ´ ´ CAP´ ITULO 1. . no ofrecen toda la versatilidad y potencia de una completa O.O. y ofrecer otro tipo de soluciones cuando la O. .

1. tenemos objetos que se comunican entre s´ que tienen un determinado ı. o a A grandes rasgos. estado interno.objeto era equiparable o a la relaci´n tipo . . Pero ¿qu´ significan todos estos t´rminos? e e Eso es lo que definiremos en este tema. entre ellos e constructores. Se definen una serie de m´todos. Clases Ya comentamos en el tema anterior que la relaci´n clase . como ya hemos comentado. podemos decir que una clase es una plantilla que define c´mo han o de ser los objetos que pertenezcan a ella. e e 9 .variable (p´gina 6).Cap´ ıtulo 2 Elementos b´sicos de la Orientaci´n a o a Objetos En un programa. En Java: [MODIFICADORES] class Nombre [extends clase] ----------[implements interface.. . que permiten instanciar ´ crear objetos de esa clase y manejarlos.. 2.] ---------{ \\ Atributos \\ M´todos e } 1 Estos m´todos especiales se denominan m´todos constructores... que pertenecen a una clase. e Prop´sito de creaci´n de nuevos objetos: la propia clase ha de definir m´todos o o e para crear sus objetos1 . o La definici´n formal de clase abarca dos aspectos: o Definici´n estructural: se define el estado y comportamiento de los objetos de o esa clase (atributos y m´todos).

2 Agrupaci´n de clases. o ∗ final → clases que no pueden extenderse con subclases. las dem´s empiezan con una may´scula. Ejemplo: public class Caja { // Atributos private int value. o . y si contienen m´s de una u a palabra. Si una clase implementa un interfaz. // M´todos e public Caja() { value = 0. le da cuerpo a esas funciones. u • Los nombres de atributos. ∗ abstract → clases que no pueden instanciarse. Convenios: Puesto que Java distingue may´sculas y min´sculas. ELEMENTOS BASICOS DE LA ORIENTACION A OBJETOS Donde los modificadores pueden ser: ∗ public → clases que son accesibles desde fuera del paquete (m´dulo2 ) en que est´ deo a finida. s´lo se definen para ser extendidas.10 ´ ´ CAP´ ITULO 2. con min´sculas. } public int getValue() { return value. se siguen las siguientes pautas: u u • Los nombres de clases van con may´sculas. Los interfaces son clases especiales que pueden contener nombres de funciones pero nunca sus implementaciones. } public void setValue(int v) { value = v. } } Cuando no se utiliza la cl´usula extends es como si pusi´semos: a e class Caja extends Object -----Todas las clases heredan de la clase Object. u • Los nombres de funciones empiezan con min´scula. sin dejar espacios ni poner otro a u tipo de caracteres intermedios delimitadores o similares.

3. Caracter´ ısticas procedimentales: que modelan el comportamiento (m´todos). Se cona sigue a trav´s de un OID (Object Identifier. Caracter´ ısticas declarativas: usadas para determinar el estado (atributos y su valor). OBJETOS 11 Los m´todos constructores se definen con el nombre de la clase.2. 2.2. 2. o Identidad La identidad es la propiedad de un objeto que lo distingue de todos los dem´s. 2. e pues aunque no se pongan existe uno por defecto que inicializa todos los atributos a 0 ´ a o NULL. Es algo interno que genera y gestiona el sistema y que no se puede ver ni modificar. x = new Caja(). Definici´n o Un objeto puede definirse como: → Colecci´n de operaciones que comparten un estado (todas referidas al mismo). o → Encapsulaci´n de un conjunto de operaciones y m´todos que pueden ser invocados o e externamente y que recuerdan el estado. aunque objetos de las mismas caracter´ ısticas se agrupen bajo la misma clase. Objetos Creaci´n de objetos o Se hace de la siguiente manera: Caja x. los propios objetos son siempre punteros por razones de asignaci´n din´mica en tiempo de ejecuci´n de espacio de memoria en o a o 3 Un objeto puede contener a otros. . ). . --x. uno y distinto de otros.. agregaci´n3 .2.2.2. de hecho.2.2.1. e Caracter´ ısticas estructurales: que organizan los objetos unos con respecto a otros (relaciones de herencia. 2.setValue(7). . No son obligatorios. Caracter´ ısticas principales Un objeto ha de tener: Identidad: debe ser identificable. Suele basarse en punteros y direcciones. Identificador de Objeto) independiente e del estado (valor de los atributos) del objeto.

e A la hora de comparar dos objetos distinguimos dos situaciones: Identidad: dos objetos son id´nticos si son el mismo objeto. ¿qu´ ocurre cuando queremos copiar un objeto? Existen dos “tipos” de e copias: la copia superficial y la copia profunda. cambia el valor de y efecto colateral-) Iguales (Aqu´ no) ı Ahora bien. a Otros modificadores son tambi´n static. Dos objetos son profundamente iguales si sus atributos son recursivamente iguales. usado para constantes. o 5 4 . En o ambos casos se trata siempre de objetos iguales. por bloques de activaı ci´n. protected y package6 . en la primera se almacenan. ELEMENTOS BASICOS DE LA ORIENTACION A OBJETOS la pila (stack) y el mont´culo (heap). private. obviamente. en todos los niveles. y final. e Igualdad: dos objetos son iguales si tienen el mismo estado (los mismos valores de sus atributos)4 . pero OID1 = OID2 . es decir. Un m´todo o atributo protected es visible desde las subclases y tambi´n desde las dem´s clases e e a pertenecientes al mismo paquete. que definiremos a continuaci´n. que hablamos de objetos de la misma clase.12 ´ ´ CAP´ ITULO 2. Suponemos. los punteros a los objetos y as´ pueden usarse offsets (desplazamientos) para acceder o ı m´s r´pidamente. Caracter´ ısticas declarativas Se usan los llamados modificadores de acceso para calificar los m´todos y atributos e 5 que determinar´n el estado del objeto: public. Esta definici´n no es recursiva. (en tiempo de compilaci´n no podr´ hacerse con los objetos en s´ sin a a o ıa ı conocer qu´ tamanho tienen) mientras que en el segundo se almacenan los propios objetos. 6 Opci´n por defecto. Dos objetos son superficialmente iguales si los atributos de los objetos son iguales. o La copia superficial est´ implementada en el m´todo sobreescribible clone de la clase a e Object a la que pertenecen todos los objetos. Id´nticos e (Si cambiamos el valor de x. OID1 = OID2 . usado con atributos que no pertenecen a un e objeto particular sino a la clase.

punteros. un unico tipo de retorno permitido. como hemos comentado. pero es habitual sobrecargarlos 7 . como hemos hecho notar. tipo de resultado. siempre pasados por valor. siempre existe uno por defecto. En cuanto a los m´todos constructores. se ejecuta “cuando quiere”. a 8 La unica pega de esta caracter´ ´ ıstica de Java es que el Garbage Collector es as´ ıncrono. e En Java no hay m´todos destructores.2. ya que su funci´n es realizada en la mayor´ de e o ıa los casos por el Garbage Collector8 . implementaci´n o c´digo del procedimiento o o 13 Los m´todos (y atributos) de clase tienen en realidad m´s utilidad de la que pueda e a parecer en teor´ pero depende del caso particular que estemos tratando. declarado en la clase Object. un mensaje se interpreta como una llamada a uno de los procedimientos del objeto pues. OBJETOS Caracter´ ısticas procedimentales (comportamiento) Siempre se dice que en POO se busca tener una determinada serie de objetos que se comunican mediante mensajes. en caso de de´ volver m´s cosas se utilizan o bien array o bien objetos que engloben a en sus atributos todo lo que se requiera. En caso de que no sea as´ siempre se puede recurrir a ı la sobreescritura del m´todo finalize. sus m´todos e determinan su comportamiento. . ıa. e El m´todo main ha de ser static porque puede llamarse para ejecutarse sin que est´ creae e do el objeto.2. son realmente referencias. 7 Sobrecargar un m´todo consiste en definir varios procedimientos con el mismo nombre pero con e par´metros distintos. no tenemos e por qu´ definirlo nosotros. son su “interfaz” para interactuar con ´l. que al ser. e Los m´todos constan de: e firma o cabecera. compuesta a su vez por: nombre tipo y nombre de par´metros. salvo en a el caso de los objetos.

ELEMENTOS BASICOS DE LA ORIENTACION A OBJETOS .14 ´ ´ CAP´ ITULO 2.

e 1 2 Fue uno de los dise˜adores de UML. Elemento clave: la clase. se a˜aden: a n Polimorfismo2 . Abstracci´n o Definici´n o Representaci´n de las caracter´sticas fundamentales de algo sin incluir anteo ı cedentes ´ detalles irrelevantes. n En esta propiedad es donde reside realmente la potencia de la O. . ). La o Programaci´n Orientada a Objetos fomenta el uso de abstracciones (clases. especificar su estado y m´todos para modificarlo). 3 M´s bien caracter´ a ısticas de los lenguajes. plantilla para crear objetos. m´todos. . o Encapsulamiento o encapsulaci´n. Tipificaci´n y ligadura3 .O.1. o La abstracci´n es fundamental para enfrentarse a la complejidad del software.Cap´ ıtulo 3 Propiedades b´sicas de la a Orientaci´n a Objetos o Tradicionalmente se han tomado como propiedades b´sicas de la Orientaci´n a Objetos a o 1 las caracter´sticas de Booch . Jerarqu´ ıa. 15 . Adem´s. o 3. que son b´sicamente cuatro: ı a Abstracci´n. o e especificadores de acceso → privacidad. o Modularidad.

Modularidad Definici´n o Propiedad que tiene un sistema que ha sido descompuesto en un conjunto de m´dulos que han de ser cohesivos y d´bilmente acoplados. e 3. el encapsulamiento y la modularidad. Que sean d´bilmente acoplados indica que se minimiza la dependencia o o e 4 entre ellos . a ◦ Permite que cambios en el dise˜o s´lo afecten de forma local. Ventajas ◦ La fragmentaci´n disminuye la complejidad. lo que tambi´n contribuye a una menor complejidad y tambi´n a una mayor comprensi´n del e e o programa. que limitan la visibilidad de m´todos y atributos. o Abstracci´n y encapsulamiento son complementarios: la primera se centra en el o comportamiento observable del objeto y el segundo en la implementaci´n (m´todos. . o Existe relaci´n entre la abstracci´n. atrio e butos). o Ventajas ◦ Permite un razonamiento m´s eficiente al eliminar los detalles de bajo nivel. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS 3. son o o conceptos sin´rgicos. Encapsulamiento Definici´n o Proceso de almacenamiento en un mismo compartimiento de los elementos de una abstracci´n que constituyen su estructura y comportamiento. .16 ´ ´ CAP´ ITULO 3.2.3. Contribuye a la ocultaci´n de la informaci´n: parte p´blica (interfaz ) y parte o o u privada (implementaci´n). o ◦ Crea fronteras bien definidas y documentadas dentro de un programa. . persiguen el mismo fin. o e Que dos m´dulos sean cohesivos significa que agrupan abstracciones que guardan alguo na relaci´n l´gica. n o En Java se materializa mediante los especificadores de acceso aplicados en las clases. mejor estructuraci´n. 4 Estos conceptos no son exclusivos de la POO. e ´ encapsulacion Un objeto definido alrededor de una abstracci´n modularidad o Encapsulamiento y modularidad son barreras alrededor de esa abstracci´n para proo tegerla.

MODULARIDAD 17 3. o e o o no a todos. e 2) Composici´n: propiedad de que los m´dulos se combinen libremente para producir o o nuevos sistemas. o u o Pocas interfaces: Cada m´dulo debe comunicarse con el menor n´mero de m´dulos posible.3. o 1) Descomposici´n: el software debe ser descompuesto en un n´mero de subproblemas o u menos complejos que est´n interconectados mediante una estructura sencilla y que e sean independientes (lo suficiente como para poder trabajar por separado en ellos. Para que estos criterios se vean satisfechos debe atenderse a los siguientes principios de dise˜o: n Correspondencia directa: La estructura modular (del sistema) software tiene que ser compatible con cualquier otra estructura modular que hayamos obtenido en el proceso de modelado. n Interfaces expl´ ıctias y legibles: Se deben especificar claramente los datos y procedimientos que se muestran o no al exterior.3. con la posibilidad de ser completamente ajenos a aqu´l en que se e desarroll´ el m´dulo.3. . o o 3) Comprensibilidad: m´dulos comprensibles sin necesidad de examinar aqu´llos otros o e con los que interact´an. o 5) Protecci´n: cuando se produce un error o situaci´n anormal o no prevista en un o o m´dulo debe quedar confinado en ´l o bien propagarse s´lo a los m´dulos “vecinos”. d´bil acoplamiento). comprensibles en s´ mismos. 5 Meyer fue el creador de Eiffel. u 4) Continuidad: peque˜os cambios en las especificaciones del problema han de provocar n pocos cambios en pocos m´dulos. o e Ocultaci´n de informaci´n: S´lo se muestra la parte del m´todo que se necesita o o mostrar. con el fin de evitar la propagaci´n de errores.1. 5 Criterios de Modularidad de Meyer Son una serie de directivas que definen lo que se admite como una correcta modularizaci´n en un programa. o en el peor caso analizando u ı el menos n´mero posible de ellos. o Interfaces peque˜as: La cantidad de informaci´n que se pasa ha de ser lo m´s pen o a que˜a posible.

Al compilar. constituyen la ordenaci´n f´ o o ısica. o Organizan los ficheros fuente.. encapsulan m´todos y atributos e y permiten ocultar informaci´n (private.java. S´lo puede haber una clase o p´blica por fichero. el nombre puede ser cualquiera. ıa o o Existen dos tipos de jerarqu´ ıas: ◦ Generalizaci´n / especializaci´n: herencia es un . . Agrupan clases con funcionalidades similares. y el nombre de ´ste ha de coincidir con el de aqu´lla. u e e Si no contiene ninguna. constituyen una ordenaci´n l´gica. public. ). 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS En Java: clases Son el primer paso de la modularidad. se usan b´sicamente como unidades de como a pilaci´n. puesto que hacen lo mismo con las clases que ´stas con sus o o e componentes.4. .2. o paquetes Son el segundo paso de la modularidad.nombreclase).. . protected.3. . Jerarqu´ ıa Definici´n o Una jerarqu´ es una ordenaci´n o clasificaci´n de las abstracciones.class por cada clase que est´ presente en el fichero. ficheros Con extensi´n . se genera un . e 3. Objetivos de los paquetes Son dispositivos de modularidad de nivel superior a las clases. lo que favorece la reutilizaci´n6 .18 ´ ´ CAP´ ITULO 3.borland. a Previene conflictos de nombre (nombrepaquete. lo cual: Favorece la comunicaci´n entre las clases. o Facilita la localizaci´n. o 6 Tambi´n suelen usarse los dominios de Internet al rev´s: com. o o ◦ Agregaci´n (objetos que contienen otros objetos): es parte de . o Favorece que se vea claramente que est´n relacionadas. e e .

la herencia presenta un conflicto con la encapsulaci´n. metemos en realidad m´s c´digo del que realmente neıas a o cesitamos. o o ♠ Incrementa la fiabilidad del mismo c´digo al extender clases ya probadas. o o ♠ Permite la consistencia entre las interfaces. . a 7 sin embargo. ). ız u No obstante. Herencia La herencia es un tipo de jerarqu´ de abstracciones en la que existen una serie de ıa subclases (abstracciones especializadas) que van a heredar caracter´ ısticas de una o varias superclases (abstracciones generalizadas). . ♠ Permite y favorece el polimorfismo. rapid application developıas ment). Visual Basic. una vez creado.4. e a Es decir. o o 7 Extensi´n implica tanto definici´n de m´s m´todos como redefinici´n de m´todos. la econom´ ıa de expresi´n (reutilizaci´n). Inconvenientes ♣ Debemos recordar siempre que medida que se a˜aden complejidades. se pretende que sea modificado lo menos posible. puesto que la o viola sobre todo a trav´s de la caracter´ e ıstica protected.4. est´ abierto. o Ventajas ♠ Favorece la reutilizaci´n de c´digo al extender clases que ya existen. o o a e o e . el principio abierto-cerrado que dice que los m´dulos han de ser abiertos y cerrados a la vez. o ♣ Al incluir librer´ enteras. no lo es en realidad porque se refiere a cosas distintas: o Un m´dulo es abierto si est´ disponible para ser extendido con facilidad. a ser modificado mediante la extensi´n . tanto a los n lenguajes como a nuestras propias aplicaciones) disminuye la velocidad de ejecuci´n. Esto que o puede parecer una contradicci´n. Existe un principio. o o La herencia define una estructura en forma de ´rbol. ♠ Favorece el desarrollo de librer´ de componentes (RAD.1. JERARQU´ IA 19 3.. n ♣ Aumenta la complejidad de comprensi´n: problema del yo-y´ (uso excesivo).3. El objetivo fundamental de la herencia es. o a Un m´todo es cerrado si su interfaz es estable y est´ bien definido. En muchos lenguajes existe un a nodo ra´ com´n (clase Object de Java. con lo cual aumenta el tama˜o del nuestro. como el de la POO en general. o ♠ Permite la compartici´n de c´digo fuente.

o a ¿Qu´ m´todo usar? En el caso de la izquierda suele sobreescribirse uno por otro. de modo que su unico objetivo es ser extendida por la herencia. los conflictos que genera su utilizaci´n. en e e el de la derecha. Las variae u bles son impl´ ıcitamente static y final. a Entre sus inconvenientes. sino que cada lenguaje los resuelve a su manera8 . e El problema en realidad no es que haya conflictos. Java. o se heredan ambos m´todos y se renombra uno de ellos. o bien se escoge uno arbitrario en el orden en que se indican. que da m´s problemas o a que soluciones: el c´digo se vuelve m´s confuso. o se le pregunta al usuario. pues ahora se hereda la cabecera de modo que los problemas que analiz´bamos antes desaparecen (salvo si devuelven tipos distintos). a Se permite una conexi´n entre ambas jerarqu´ (una clase puede extender una supero ıas clase y al mismo tiempo implementar alg´n intefaz): u 8 Java no soporta herencia m´ltiple. ıa u Minimizan los conflictos. Sus caracter´ a ısticas son que incluye una serie de m´todos que por defecto son p´blicos y abstractos. o Clases abstractas e interfaces La caracter´ ıstica principal de una clase abstracta es. que no puede ser instanciada. como ya sabemos. Cuando se tiene herencia m´ltiple la estructura deja de ser en ´rbol y pasa a ser un u a grafo dirigido ac´clico (GDA). por ello lenguajes como Object Pascal. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS La herencia puede ser simple (desciende de una unica superclase) o m´ ltiple (des´ u ciende de varias superclases). ´ Un interfaz supone un paso m´s. pero permitiendo en esta caso la herencia m´ltiple. u . es decir. ı Entre las ventajas de la herencia m´ltiple tenemos que es un mecanismo muy potente u que nos proporciona mucha m´s flexibilidad. contantes de clase. Siguen entre ellos una jerarqu´ paralela a las clases. una clase abstracta “total”.20 ´ ´ CAP´ ITULO 3. C# (surgidos de C++) han eliminado la herencia m´ltiple y simplemente la simulan mediante implementaci´n (y u o compartici´n) de interfaces.

♦ Se pueden usar como marcadores de clase (interfaces vac´ ıos).1416. public int NUMFILAS = 15... los interfaces son utilizables en m´s ´mbitos: a o a a ♦ Para capturar similitudes sin forzar relaciones de clases. if (x instance of Serializable) . } Tipos de herencia La herencia lleva impl´ ıcito el principio de sustituci´n: el tipo indicado en la deo claraci´n de una variable puede no coincidir con el tipo que contiene la variable en el o momento actual (se puede declarar como de la clase y luego ser de la subclase... e ♦ Para definici´n de nuevos tipos de datos.. ♦ Para revelar la interfaz de un objeto (m´todos de acceso) sin revelar la clase. matriz [0][0] = new Imagen(). Hay que diferenciar: . } 21 Adem´s. IM { . .4. JERARQU´ IA class A extends B implements IX. MiClase x = new MiClase(). S´pase que de un interfaz no se pueden o e crear objetos. donde ahora va un tipo luego puede ir otro)...3... aunque s´ puede haber objetos que los implementen: ı interface Celda.. { } class Imagen implements Celda { } . Celda [][] = matriz. en el API de Java tenemos el ejemplo: class MiClase implements Serializable { } . al no introducir c´digo alguno.. ♦ Se puede usar como contenedores de constantes globales: interface Constantes { public double PI=3..

Los ıa a lenguajes de POO suelen entender subclase = subtipo y permiten por tanto el principio de sustituci´n. las subclases son versiones especializadas a u de las superclases.22 ´ ´ CAP´ ITULO 3. o o o pero en las subclases se aprovechan funcionalidades de las superclases. ´ Herencia de Especificacion Una superclase declara unos m´todos (abstract) que son implementados por las sube clases. return item. o ´ Herencia de Especializacion Es el tipo m´s com´n de herencia. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS subtipo: relaci´n de tipos que reconocen expl´ o ıcitamente el principio de sustituci´n . return obj. } } . subclase: B es subclase de A si la extiende a trav´s de la herencia (de los e supuestos anteriores s´lo se cumple el primero). 2. ´ Herencia de Construccion No existe relaci´n l´gica entre subclases y superclases (no existe relaci´n de tipo es un). Para que esto se cumpla. Una instancia de B puede ser legalmente asignada a una variable de tipo A. o La mayor´ de las veces las subclases son subtipos. Una instancia de B asignada legalmente a una variable de tipo A puede ser utilizada por la variable de tipo A sin un cambio observable en su conducta. para poder decir que B es subtipo o de A son necesarias dos condiciones: 1. en ella. removeElementAt(size()-1). Ejemplo t´ ıpico: class Stack extends Vector { public Object push (Object item) { addElement(item). } public Object pop () { Object obj = peek(). aunque no est´n obligadas. } public Object peek () { return elementAt(size()-1).

public int elementAt (int index) throws IllegalOperation { throw new IllegalOperation(‘‘elementAt’’). empero. esta t´ctica no es muy “efio a ciente”. que implementa la filosof´ es parte de. a u Java y otros lenguajes. pues imaginemos que hubiese que hacer esto para casi cada uno de los m´todos e de la superclase. podr´ usarse.3.4. aunque realmente no es lo mismo porque no heredamos c´digo. e o 3.. ıa ´ Herencia de Combinacion Consiste en heredar de m´s de una superclase (herencia m´ltiple). No cumple. eliminar un ıan elemento del medio). lo simulan con interfaces.. Es un caso particular de la herencia de especializaci´n.4. puede opo a tarse por emplear la composici´n. Nos plantea si realmente se deber´ estar usando la herencia o no. por ejemplo..2. aunque o ıa . jar´ de respetarse las directivas que hacen de la pila lo que es (por ejemplo. para evitar efectos no deseados del ıa tipo: . a En el ejemplo anterior. } } Aunque soluciona las pegas de la herencia de construcci´n. class IllegalOption extends Exception { IllegalOperation (String str) { super(str). por tanto. o ´ Herencia de Limitacion La conducta de la subclase es m´s restrictiva que la de la superclase. como hemos dicho. } . que una pila sea un subtipo de Vector. Alternativas a la herencia: la Composici´n o En los casos en los que la herencia no parece la soluci´n m´s adecuada. podr´ hacerse y no fallar´ pero deıa ıa. el principio de sustituci´n. JERARQU´ IA 23 No se puede decir.. no es l´gico que o donde tenemos un vector podamos meter una pila. s´lo se a˜aden o n m´todos. o ´ Herencia de Extension Se da cuando se hereda de una superclase pero no se redefine nada.

size()-1). } public Object pop() { Object resultado = datos.addElement(nuevoValor). la herencia evita tener que llamar a dos funciones (deo legaci´n).lastElement(). datos.isEmpty(). } En relaci´n con lo anterior.lastElement(). return resultado. e . Aparece cuando un objeto o e est´ compuesto o agrega (jerarqu´a de agregaci´n) varios objetos. } } De este modo se utiliza lo que se quiere de la “superclase” y no se heredan m´todos o e atributos innecesarios. es decir. pero en otras ocasiones se requiere. } public void push (Object nuevoValor) { datos.24 ´ ´ CAP´ ITULO 3. } public boolean isEmpty() { return datos. o Los elementos protegidos no pueden usarse si se utiliza la composici´n10 . ı.isEmpty(). ya que no hay m´todos de o e enlace. Ventajas de la herencia sobre la composici´n o El principio de sustituci´n a veces no es deseado. public Stack () { datos = new Vector(). o con la composici´n no es posible nunca. o 9 10 Una Stack no es ni tampoco es parte de un Vector. a ı o Por ejemplo: class Stack { private Vector datos.removeElementAt(datos. En Java s´ siempre que est´n en el mismo paquete. o Con la herencia tenemos menos c´digo que mantener. m´todos del estilo: e public boolean isEmpty() { return datos. } public Object peek(){ return datos. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS a la distinci´n entre ´sta y la es un no est´ demasiado clara9 .

distinto c´digo para tratar los distintos tipos. Con la composici´n se puede reimplementar la clase para utilizar otro mecanismo o de almacenamiento11 . como podemos deduo a cir.1. Ml. . La composici´n. El problema es que agrupa varios conceptos.5. variables a que pueden contener valores de distintos tipos. de modo que una funci´n que pueda parecer o o polim´rfica en realidad estar´ implementada a trav´s de varias funciones monom´rficas. 14 No existe en Java. 12 11 . o a e o 3. Generalmente suele aplicarse a funciones que aceptan par´metros de diferentes tipos. utilizar otro elemento que no fuese un Vector. en el caso particular de las pilas. de suerte que se puede o a aplicar sobre diferentes tipos. Polimorfismo El polimorfismo es. Que sobre la pila puedan aplicarse m´todos de la clase Vector.5. subclase de Animal.5. . se indican con claridad e las operaciones a utilizar. con m´todo getNombre que si no se redefine es el mismo e para ambos. como ya vimos. POLIMORFISMO Ventajas de la composici´n sobre la herencia o 25 Puesto que componiendo no se heredan m´todos no deseados. es tambi´n un inconveniente). En C++ se le llama generidad ´ genericidad y est´ basado o a en la definici´n de “plantillas”: o Por ejemplo. si queremos consentir o no el mencionado principio de sustituci´n.. e 13 Ejemplo: Clase Perro. Polimorfismo Universal Param´trico e Este tipo de polimorfismo es propio de los lenguajes funcionales (Lisp. El Polimorfismo Ad-Hoc se llama tambi´n Aparente (y en contraposici´n el Unie o versal es Verdadero) porque da la impresi´n que lo hay pero en realidad no es as´ Se utiliza o ı. . e La composici´n permite simular la herencia m´ltiple mediante varios objetos privao u dos internos. )14 y consiste en definir una funci´n pero no el tipo de sus par´metros. . o 3. al no cumplir el principio de sustituci´n. como su propio nombre indica..3. la caracter´ ıstica de algo que puede adoptar o tiene varias formas. Lo determinante para decidir entre herencia y composici´n ser´. pueden tener un tipo declarado y almacenar otro) y se utiliza el mismo c´digo para o 13 todos . impide polimorfismos no o o deseados12 (lo cual. Distinguimos algunas variantes que exponemos a continuaci´n clasificadas seg´n la o u Divisi´n de Cardelli y Wegner : o  ´ Parametrico   Universal o Verdadero   ´ De Inclusion  Polimorfismo   Sobrecarga   Ad-Hoc o Aparente  ´ Coaccion En el Polimorfismo Universal existen valores (atributos) con distintos tipos (es decir.

. void abrirFichero().2. ¿qu´ quiere decir? e 16 15 . t´ e ıpico y m´s a com´n en los L. Vector. Y por tanto tambi´n en Java.26 ´ ´ CAP´ ITULO 3. n´mero y orden de par´metros..3.5. Polimorfismo Universal de Inclusi´n o Este tipo de polimorfismo es el que se consigue a trav´s de la herencia.. Sobrecarga Param´trica e Dentro de una misma clase pueden existir varios m´todos con el mismo nombre pero e con distinto n´mero de par´metros o par´metros de distintos tipos. Tambi´n e 16 es posible la sobrecarga entre clases ...5. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS template <classT> class Box { . 3. . 17 Si tenemos un metodo isEmpty() sobre un Rectangle. que devuelvan dos tipos diferentes: u a int abrirFichero (). Sobrecarga La Sobrecarga consiste en utilizar el mismo nombre para funciones distintas. e Las clases Hashtable. que permite que una instancia sea asignada a una variable declau rada de otro tipo. ¿cu´l ha de ejecutarse cuando se le e a llama? Se sabe por el objeto que hace la llamada. Si el resultado no se recoge en una variable ¿cu´l usamos? a Existen lenguajes no orientados a objetos que permiten este tipo de polimorfismo. Box <shape> a_Box(circle). aunque no siempre pueden querer significar lo mismo17 ... no pueden existir dos m´todos con e el mismo nombre. tienen un m´todo isEmpty(). } (double y..15 ... 3.O. que suele ser corriente fundamentalmente en sobrecarga de operadores.. int x) { . } (double x. La ventaja de usar nombres iguales para hacer los mismo sobre diferentes clases de objetos es la coherencia. } Box <int> a_Box(5). El caso m´s usual es u a a a el de los constructores: public public public public Esfera Esfera Esfera Esfera () { . } Lo que nunca puede ser igual es el tipo de retorno. .O. double y) { . } (int x. double y) { .

n } } class A extends Personal { long numProyectos. En tiempo de ejecuci´n se mira qu´ tipo hay en P y ejecuta el m´todo correspondiente. en tiempo de o ejecuci´n: o Personal P = new A(). protected long a~os. La sobrecarga se decide en tiempo de compilaci´n. long sueldo() { return (10000*numProyectos). } } Siempre que hay sobreescritura ⇒ hay sobrecarga (entre clases). n long sueldo() { return (base+10000*a~os). P.6. siempre que los par´metros sean iguales. o e e A esto se le llama ligadura din´mica y lo veremos en la secci´n siguiente (3. la sobreescritura. e de Refinamiento Se refina el comportamiento del m´todo de la superclase.3. a o a . long sueldo() { return (super. POLIMORFISMO Sobreescritura 27 Es un caso particular de sobrecarga que se da cuando se sobrecarga un m´todo que e est´ en la superclase. } } class B extends Personal { long extra. ya que si son distintos se a a considera simplemente sobrecarga.5. p´gina 28). La sobreescritura se puede clasificar a su vez en: de Reemplazo Se sustituye el m´todo de la superclase por otro. Lo contrario no siempre es cierto.sueldo()+extra). e Veamos un ejemplo de cada una: abstract class Personal { protected long base.sueldo().

formalmente. suma de enteros y suma de reales. pues a partir de los tipos existentes se pueden o crear tipos nuevos. a veces no se sabe distinguir si lo que hay es sobrecarga o coacci´n: o 3+4 3. no obstante. Lo que se persigue con los tipos es una idea de congruencia. coercion. Tipificaci´n o Un tipo es una caracterizaci´n precisa de las propiedades estructurales o de o comportamiento (atributos. o o Un mecanismo de composici´n.0 ¿Es esto un operador sobrecargado 4 veces? ¿O son dos funciones. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS 3.28 ´ ´ CAP´ ITULO 3. combinadas con la coacci´n de enteros si hay reales presentes? ¿O hay o s´lo una funci´n suma y siempre coacci´n de enteros a reales? o o o 3.0 3. ¿Qu´ relaci´n hay entre tipos y clases? Los lenguajes O.3. b´sicamente.6. e . o Cada lenguaje las interpreta y presenta de forma particular y espec´ ıfica. pues las entidades de un tipo se agrupan seg´n o u sus propiedades y conducta. hacen (por sencillez) que no e o haya pr´cticamente ninguna diferencia. que evita errores y garantiza correcci´n.1. x=i+8.5. Tipificaci´n y ligadura o Las ultimas caracter´ ´ ısticas que nos quedan por ver es la tipificaci´n y la ligadura. pero definiremos unos rasgos generales. la diferenciaci´n que a o se suele hacer subraya que un tipo especifica una sem´ntica y una estructura y una clase a es una implementaci´n concreta de un tipo: o 18 Del ingl´s. e Con los tipos se consiguen 3 objetivos: Un mecanismo de abstracci´n.O.0+4.6. Coacci´n o La coacci´n18 es. 3.0+4 3+4. m´todos) que comparten una serie de entidades. int i. una conversi´n impl´ o a o ıcita de tipos que se da en casos como: real x.4. Lo que se hace es en primer lugar convertir i a real y luego realizar la operaci´n. o No obstante. Un mecanismo de protecci´n.

O. La consistencia exige que se cumplan 3 restricciones: o ◦ Restricci´n de Declaraci´n: Todas las entidades del lenguaje han de tener o o un tipo declarado.. para poder meterlos donde se requiere un Object). ).. char. Comprobaci´n de tipos Estricta o Fuerte o Requiere que todas las expresiones de tipos sean consistentes en tiempo de compilaci´n. Boolean. las clases suelen definir un tipo. boolean. .6. . Object getValue(). TIPIFICACION Y LIGADURA PilaArray | |--> push() |--> pop() |--> peek() PilaLista | |--> push() |--> pop() |--> peek() 29 PilaArray y PilaLista son dos clases distintas pero son el mismo tipo (pila)..O. que a no son ni se implementan a trav´s de clases (int. En Java. las funciones y sus par´metros tambi´n. . . Es bastante restrictivo. o y es la que se lleva a cabo siempre en los lenguajes no orientados a objetos. void setValue(). Character. y a parte existen los tipos b´sicos. } Comprobaci´n de tipos o Hay varias forma de hacerlo: Forma Est´tica a Forma Estricta o Fuerte Forma Din´mica o D´bil a e Aunque en ocasiones las dos primeras se agrupan bajo el segundo nombre.. En los L.. class Integer { private int i.. se definen clases contenedoras (del ingl´s wrapped classes): e Integer.´ 3. a e . para que e podamos tratarlos como clases cuando lo necesitamos (por ejemplo. . Comprobaci´n de tipos Est´tica o a El tipo exacto se determina en tiempo de compilaci´n. .

pero la ligardura consiste en ligar o o relacionar la llamada de un m´todo con el cuerpo del m´todo. caracter´ e ıstica o variable) el m´toe do f ha de estar definido en x o en alguno de sus antecesores. Ventajas de la tipificaci´n o Las ventajas de ser estrictos con los tipos son: Fiabilidad. pueden hacerse optimizaciones.. o Legibilidad.)numProyect(). En realidad esto podr´ funcionar. Ligadura En ocasiones puede confundirse con la tipificaci´n.numProyect(). pues al detectar los errores en tiempo de compilaci´n se corrigen antes. o por tanto. que posee el atributo numProyect. P. ya que proporciona cierta “documentaci´n” al c´digo. siempre que sean e subtipos). o a a C++. Es decir. aplica el pesimismo: Personal P = new A(). puesto que P contiene un objeto de tipo ıa A. un mayor n´mero de excepciones). Comprobaci´n de tipos Din´mica o D´bil o a e Todas las comprobaciones de tipos se hacen en tiempo de ejecuci´n (se dan. Esta comprobaci´n es m´s flexible que la est´tica y es la que tienen Java. a Ejemplo: Smalltalk. o o Eficiencia. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS ◦ Restricci´n de Compatibilidad : En una llamada x=y o func(x) donde se o pase y en lugar de x. . f m´todo. en otros lenguajes. ıa exige una conversi´n expl´cita: o ı ((A) P. . 3. En caso de “duda”.6. ◦ Restricci´n de llamada a caracter´stica: Para que sea posible hacer una o ı llamada x. e e Se da en casos de sobreescritura: . pero si no lo tuviese (suponer que la asignaci´n a P estuviese en un if o algo as´ ser´ un error. de modo que Java o ı). se requiere que y sea compatible con x (y es compatible con x a trav´s de la herencia. Object Pascal. pero nos topamos con muchos m´s problemas a la hora de ejecutar. .2.f (x clase. la flexibilidad es mucho u mayor.30 ´ ´ CAP´ ITULO 3. atributo.

Recordemos que si una clase es final. 20 19 ... ıa Hay compiladores que incluyen llamadas “inline”. 31 Podr´ optarse por una soluci´n est´tica y ejecutar el m´todo sueldo() de la clase ıa o a e Personal. . pero probablemente no ser´ lo deseado. a No todos los m´todos permiten ligadura din´mica. aunque la penalizaci´n que ´sta impone es constante. . de modo que se escoge en tiempo de ıa ejecuci´n (en base al tipo actual. no al tipo declarado). pues lo predeterminado es que se liguen est´ticamente20 .. en Java. los m´todos e a e final. que se decide en tiempo de compilaci´n. Se estudia la VMT de los objetos de dicho tipo y se localiza la entrada correspondiente al m´todo. o La ligadura est´tica es v´lida si produce los mismos a a resultados que la ligadura din´mica. En contraposici´n con la ligadura est´tica. a Esto puede hacernos pensar que quiz´s lo mejor fuese que todo lo decidiese el compia lador. no o e depende del nivel de una jerarqu´ en que se encuentre. a a Todos los objetos tienen una tabla de m´todos virtuales (VMT.sueldo(). la ligadura est´tica tambi´n tiene inconvenientes. todos sus m´todos lo e e son. El resto de los m´todos en Java emplean ligadura din´mica por defecto. . Se sigue el puntero y se ejecuta el c´digo al que apunta. ya que no permite la a e reutilizaci´n e incumple el principio abierto-cerrado. a No obstante. que no permiten ser sobreescritos. se necesita definir los m´todos como virtual para e que empleen esta t´cnica (por razones de eficiencia. por eso recibe el nombre de o ligadura din´mica19 . usan siempre ligadura est´tica.. virtual method e table). Por ejemplo. . a o 21 Es el motivo de que otros lenguajes intenten eludirla.´ 3. se siguen los e o pasos: Se comprueba el tipo actual correspondiente al objeto que solicita la ejecuci´n del o procedimiento. es la eficiencia21 . algo que evita e o n el paso de par´metros por la pila. o El principal problema que se le achaca a la ligadura din´mica. Para decidir qu´ c´digo se utiliza ante una determinada llamada. else P = new B(). Igual situaci´n se a o da con los m´todos privados. TIPIFICACION Y LIGADURA Personal P. lo que consiste en incluir el c´digo o de un m´todo en el lugar de la llamada (s´lo con procedimientos peque˜os). Es importante hacer notar que el orden de ´stos en dicha tabla e e ´ en una jerarqu´ no varıa ıa. . o a o Debe tenerse especial cuidado en no confundir la ligadura din´mica con la comprobaci´n de tipos.6. como C++ u Object Pascal. En otros e a lenguajes. . ya que l´gicamente la ejecuci´n es e o o m´s lenta). P = new A(). if .. P. como ya hemos dejado a entrever.

32 ´ ´ CAP´ ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS .

. un o programador de sucesos discretos. Object Pascal. Tambi´n se desarrolla e Smalltalk. . icons. que representan la tendencia actual (lenguajes totalmente orientados a objetos que evitan. . podemos observarlo en un gr´fico dirigido que plasme esta a historia m´s o menos reciente: a ´ antecedentes historicos El concepto de Orientaci´n a Objetos surge a partir del lenguaje Simula-67. como decimos. creador de una m´quina o a universal (Flex o Dynabook) basada en los conceptos de clase y herencia del Simula-67 y del Lisp. o El padre de la Orientaci´n a Objetos es Alan Kay. Eiffel. mouse and pointers (Xerox.Cap´ ıtulo 4 Evoluci´n de los Lenguajes o Orientados a Objetos Lo m´s importante a la hora de analizar alg´n diagrama que muestre esta evoluci´n1 a u o es que distingamos entre los llamados lenguajes puros. o o Ya en los 80. que eliminan las cosas molestas como la herencia m´litple) y los lenguajes h´ u ıbridos como C++. con Smalltalk. por ejemplo. En los a˜os 70 la Orientaci´ a Objetos y la Inteligencia Artificial comienzan n o a interrelacionarse de forma estrecha: Aparecen extensiones a lenguajes (Common Lisp Object System o CLOS).. etc. . Apple). se acu˜a el t´rmino n e Orientaci´n a Objetos. entornos de programaci´n (Kee. o Las teor´ de herencia de la Orientaci´n a Objetos influyen en el desaıas o rrollo de esquemas de representaci´n del conocimiento. El resto.. 33 . y permite ahora la reutilizaci´n del software. Para combatirlo. ART). tiene su auge el desarrollo de interfaces de usuario WIMP: windows. En 1970. como Java. o Aparecen tambi´n los primeros problemas: como la mayor´ de los lenguajes e ıa Orientados a Objetos estaban muy influenciados por el desarrollo de interfaces de usuario no eran eficaces en otros campos de programaci´n. o 1 Como el que tenemos en transparencias. o Se integran la Orientaci´n a Objetos y la Composici´n Concurrente.

Sistemas abiertos (UNIX. APPLE Entornos LISP Entornos IA Nuevos lenguajes: Eiffel. IBM. X-Window. . . Aparecen los primeros est´ndares.. . .. En la d´cada de los 90 la investigaci´n se centra en: e o 1.1: Tabla resumen de la evoluci´n de la Orientaci´n a Objetos o o Definiciones P. . IPSE.O. as´ como el UML (Unified Modelling o ı Language). . a las grandes empresas crean los suyos propios: Microsoft.. n An´lisis O. Fase I D´cada 70: Invenci´n e o Simulaci´n de sucesos o discretos SIMULA Kay: FLEX DYNABOOK Smalltalk Fase II D´cada 80: Confusi´n e o Interfaces: WIMP XEROX.. ).. EVOLUCION DE LOS LENGUAJES ORIENTADOS A OBJETOS nacen lenguajes como Eiffel.D. Dise˜o a n Sistemas Abiertos Aplicaciones B. Ada. Este agrupamiento (OMG) crea una gu´ de arquitectura para la integraci´n de la ıa o aplicaci´n Orientada a Objetos (Corba). as´ como los modelos est´tico y din´mico del sistema que se ı a a dise˜e. 3. C++. tipos miembros de una jerarqu´ unidos u ıa mediante relaciones de herencia. Orientadas a Objetos Est´ndares a Cuadro 4. . M´todo de implementaci´n en el que los programas se organizan como e o colecciones cooperativas de objetos. nace el OMG (Object Management Group). Dise˜ o O. C++ Fase III D´cada 90 : Madurez e An´lisis. ıa 2.O. AT&T.O. M´todo de dise˜o que abarca el proceso de descomposic´n n e n o Orientada a Objetos y una notaci´n para describir los modelos l´gico o o y f´ ısico. que incluyen extensiones post-relacionales precursoras de las Bases de Datos Orientadas a Objetos. El enfoque de la Ingenier´ en el desarrollo del software: CASE. . Disposici´n de componentes de software reutilizables (lenguajes Orientados a o Objetos. . cada uno de los cuales representa una instancia de alg´n tipo de clase. Nacen las Bases de Datos Relacionales. . M´todo de an´lisis que examina los requisitos desde la persa e a pectiva de las clases y objetos del dominio. ). .´ 34 CAP´ ITULO 4.O.

o La utilidad de un modelo es la posibilidad de ser usado para: ◦ visualizar c´mo queremos que sea el sistema o ◦ especificar su estructura y comportamiento ◦ servir de plantilla que ayude al dise˜o n ´ ◦ hacer funciones de documentacion UML es tambi´n una metodolog´a de desarrollo. pero sin meternos en detalles de dise˜o. m´s “moderna” y realista. ´ a 35 . n Definici´n o Un modelo es una simplificaci´n de la realidad que busca o permite una mejor o comprensi´n del sistema que estamos analizando. igual que los modelos en cascada: e ı o en espiral o incremental : La tendencia actual es esta ultima.Cap´ ıtulo 5 UML Lo principal que veremos en este tema son diagramas de clase y c´mo permutar entre o un diagrama UML y un lenguaje como Java.

Rumbaugh y Jacobson. pretendiendo abarcar todas las t´nicas de modelaıa e do. el O. la estructura de relaci´n entre o los objetos1 . ). ◦ Documentar. a un programa a un lenguaje orientado a objetos. entre otras cosas. esto es. (Revision Task Force) en lo que a o revisi´n y evoluciones se refiere. ◦ Especificar. . que desarroll´ los est´ndares o a en orientaci´n a objetos. ◦ Construir.Object Modeling Technique -. de interacci´n. fase m´s n a espec´ ıfica en la que se describen los modelos l´gico y f´ o ısico. a a Programaci´n Orientada a Objetos.G. . ha dejado paso a la R. o y formalmente puede decirse que es: Definici´n o UML es un lenguaje de modelado basado en la representaci´n gr´fica mediante o a diagramas con el objetivo de: ◦ Visualizar. Para ello son muy importantes las dos primeras etapas: el an´lisis. o Alcance Definen el ´mbito en el que es amplicable un nombre.Object Oriented System Engineering -.T. o UML se integra en el proceso de: An´lisis Orientado a Objetos. o ı • Est´tico . pues a pesar de las diferencias el objetivo es com´n: a u dise˜ar la estructura de clases de un sistema. a n . y el dise˜o. OOSE .M. surgidos del an´lisis y o a dise˜o.. a 1 Un an´lisis muy detallado se puede tomar como dise˜o. (Object Management Group). CoadYourdon). En la actualidad. Dise˜o Orientado a Objetos. UML UML nace para solucionar la diversidad en metodolog´ orientadas a objetos (Booch. de pormenorizar los a detalles que genera el estudio de los casos de uso. UML es una metodolog´ amplia.36 CAP´ ITULO 5. que n afectan a: Nombres Definen c´mo hay que llamar a los elementos y a las relaciones entre ellos. que se ocupa. ıas OMT .F.f´sico. existen una serie de reglas. fase preliminar a en la que se examinan los requisitos y se identifican los objetos. y fue desarrollada en origen por Booch. pero sencilla a la vez. est´ m´s cerca del c´digo que el an´lisis. Para pasar de los diagramas (de clase. Consecuentemente. generando un est´ndar. identificar y establecer las relaciones n entre sus clases componentes. que refina el an´lisis hasta situarse suficientemente n a pr´ximo al programa. o a a o a Se distinguen dos tipos: • L´gico .din´mico.

atributos. de multiplicidad. nuevos bloques definidos a partir de los existentes. . los t´ ıpicos son los de visibilidad. Valores etiquetados. MECANISMOS COMUNES Visibilidad Definen c´mo se pueden “ver” los nombres. m´todos.5.1.. Mecanismos Comunes Son mecanismos comunes de UML: ∗ Especificaciones: de nombre. n o Restricciones. o o a 37 5. . .. . Ejecuci´n Definen una simulaci´n de un sistema / modelo din´mico. o Integridad Definen las relaciones de unos elementos con otros. o o ∗ Mecanismos de extensibilidad: Estereotipos.1. usados para a˜adir informaci´n. o Divisi´n entre interfaz e implementaci´n. que suelen usarse para escribir cosas de un lenguaje concreto que el est´ndar no implementa. a . . e ∗ Adornos. ∗ Divisiones comunes: Divisi´n entre bloque e instancia del bloque.

ya que en ese caso la correspondencia posterior con el lenguaje de programaci´n puede hacerse muy dif´ o ıcil. Por contrapartida.2. tampoco se debe no limitarlo en absoluto. Modelado Estructural: Diagrama de clases UML −→ c´digo o Llamamos ingenier´ directa al paso: ıa Debe tenerse cuidado de no limitar el UML tratando de ajustarnos al lenguaje que usaremos despu´s para implementarlo. que es el paso: e ıa c´digo −→ UML o El gran problema que presenta es que suele aportar demasiada informaci´n que no es o interesante para nosotros. Tambi´n se permite la ingenier´ inversa. por supuesto. encontrar el equilibrio entre ambas situaciones.38 CAP´ ITULO 5. pues se corre el riesgo de esbozar un diagrama e demasiado dependiente del lenguaje. UML 5. Lo ideal es. .

R. aunque m´s espec´ a a ıficos a´n porque est´n relaciou a nados con un lenguaje particular. los GoF (Design Patterns Elements of Reusable O. Cooper. Por tanto. un problema y una soluci´n.O. ya que es com´n o u en P. es perfectamente o n aplicable al desarrollo de software. Software. un congreso sobre Orientaci´n o a Objetos. Johnson y J. acu˜ada por el arquitecto Christopher Alexander. 39 .O. en su disertaci´n Using Pattern Languages for O. Son propios o de la fase de dise˜o.O. como Jim Coplien (Avanced C++ ıa a 1 Programming Styles and Idioms . Vlissides. Programs. Se tiene un patr´n espec´ o ıfico para cada lenguaje.O. n De Idiomas De nuevo son an´logos. Tipos de Patrones Tenemos varios: Arquitect´nicos Expresan la estructura fundamental del sistema software. o Su iniciativa ser´ seguida por m´s personajes. o El objetivo es que exista una literatura de problemas caracter´ ısticos ya resueltos para cuando se nos presente alguno similar acudir a ella y utilizar esa soluci´n. 1 En este caso el autor llama idiomas a los tipos de patrones. 1995) y M. que para ciertos problemas distintos la forma o estructura de la soluci´n que o adoptan sea similar. o al menos as´ lo entendieron Ward Cunningham y Kent ı Beck. mostrando o sus subsistemas y las relaciones entre ´stos. a De Dise˜ o Desempe˜an el mismo papel que los anteriores pero a m´s bajo nivel. con las diferencias que ello implique.1. W. pues n n a entran en c´mo son las comunicaciones entre los elementos del sistema. Gamma. R. Grand y J. 1991) y E. Esta definici´n.Cap´ ıtulo 6 Patrones de Software Definici´n o Un patr´n es una regla con 3 partes que expresa una relaci´n entre un cono o texto. Son patrones de alto nivel y se usan en e la fase de an´lsis. 6. Helm. se pretende que haya una serie de soluciones efectivas (que ya se sabe que funcionan) y reutilizables (que puedan ser usadas en contextos similares). que la adoptaron por primera vez en la OOPSLA’87.

c´mo transitar a una o o buena situaci´n. la n a a composici´n. nos ense˜a las cosas que no se deben hacer. PATRONES DE SOFTWARE En general suelen usarse los patrones de Dise˜o. o Otros indican. . o Fundamentales Son los patrones de dise˜o m´s b´sicos.2. o . . se requiere el m´ o ınimo acoplamiento para que se produzcan las menores molestias posibles en caso de modificarse la primera. Patrones de Dise˜ o n Se reconocen fundamentalmente cuatro. . los tres primeros definidos por el GoF y el cuarto por M.. . tratan del uso de interfaces.. c´mo arreglarlo (refactoring). o o 6. o Tenemos dos tipos de antipatrones: Los que definen un determinado problema y describen una mala soluci´n que lleva o a una mala situaci´n. Miena o o tras que un patr´n nos muestra una pr´ctica correcta de programaci´n.40 CAP´ ITULO 6. c´mo llevarlas a cabo para obtener las mayores ventajas.. Estructurales Tratan de c´mo realizar combinaciones para formar estructuras mayores o (agrupaciones de clases). Grand: Creacionales Tratan sobre c´mo crear instancias de los objetos de cara a hacer proo gramas m´s flexibles y m´s generales intentando abstraer lo m´ximo posible esta a a a operaci´n: cuando una clase ofrece unos servicios y otra los usa. n Adem´s de una clasificaci´n de patrones se tiene otra divisi´n: de antipatrones. . como por ejemplo los grandes n programas sin modulaci´n. algunas especificaciones de herencia. . el antipatr´n hace o a o o lo contrario. si nos encontramos en una mala situaci´n. Comportamiento Tratan de aspectos relacionados con las comunicaciones entre objetos. la herencia.

Partes de una aplicaci´n o Son principalmente tres: Interfaz del usuario: parte que.2. impresi´n. seg´n c´mo se estructuran las partes anteriores: u o ∗ Aplicaciones monol´ ıticas ´ monocapa. e o o Servicios: servicios que se ofrecen a la l´gica de la aplicaci´n (por ejemplo bases o o de datos. o ∗ Cliente/Servidor .Cap´ ıtulo 7 Objetos Distribuidos 7. ∗ Tres capas. comunicaci´n.2.. ). Es lo que distingue a unas de otras. L´gica de la aplicaci´n: toma la informaci´n de entrada del interfaz y la procesa o o o para transformarla y obtener la de salida. gestiona la informaci´n de entrada (c´mo pedirla) y la de salida (c´mo o o o mostrarla). 7. . Suele llamarse tambi´n l´gica de negocio ´ empresarial. Aplicaciones Monol´ ıticas o Monocapa Cada computador que ejecuta la aplicaci´n guarda en s´ mismo las tres partes: o ı 41 . . como su propio nombre indica. Tipos de aplicaciones Distinguimos.1. en realidad. archivos.1. o o 7. interact´a con u el usuario.

7. a √ Aumento del coste. escalar y reutilizar. supone cambiar las m´quinas. o a Hay independencia entre la aplicaci´n y los datos (que as´ pueden utilizarse en o ı otras).. .2. Cliente/Servidor Tienen el siguiente aspecto (forma m´s com´n): a u Ventajas Se reparte la potencia de proceso (la m´quina cliente no tiene que hacer todo). ). ).2.42 Ventajas CAP´ ITULO 7. OBJETOS DISTRIBUIDOS ◦ F´cil dise˜o e implementaci´n (no hay que tener en cuenta nada relativo a la comua n o nicaci´n entre distintas computadoras. . a Precisa cierta capacidad de proceso (todos los ordenadores que la ejecutan deben poder hacerlo en su conjunto). Esto tambi´n beneficia que la aplicaci´n en su conjunto sea m´s f´cil de e o a a mantener. o Poco escalable (si aumentan las necesidades computacionales o de espacio. o ◦ Adecuadas para un n´mero reducido de usuarios. ). . . . u Inconvenientes Dif´ de mantener (si hay un cambio hay que ir computador por computador acıcil tualizando la aplicaci´n en todos. a Al tener un servidor dedicado se tiene una gesti´n de los datos m´s eficiente. Inconvenientes √ Aplicaciones m´s complejas. . .

.´ 7. COMUNICACION ENTRE APLICACIONES 43 7. Inconvenientes Aplicaciones m´s complejas (que sean m´s f´ciles de mantener no implica que sean a a a m´s f´ciles de construir). Ello no quiere decir que haya n computadores. El interfaz se o convierte as´ en un servicio m´s al servicio de la l´gica. a a Cada vez hay m´s aplicaciones de este tipo. En realidad seguimos teniendo las tres capas. pueden estar varias capas en el mismo. ). sustituyendo a las de tipo Cliente/Servidor. Escalabilidad. Comunicaci´n entre aplicaciones o Partimos de que existen una infraestructura y un protocolo de red (TCP/IP. . aunque alguna de ellas se divida en subcapas. Definici´n o Hiddleware: Es el software que se utiliza entre las distintas capas para favorecer la comunicaci´n entre las mismas. o Es aqu´ donde entran en juego los objetos distribuidos.2. ı a o Ventajas Simplicidad de mantenimiento (cambios en la l´gica no hace falta distribuirlos en o todos los clientes). Tres Capas Las tres capas de la aplicaci´n residen en tres computadores distintos. ı 7. . ..3. Podemos comunicar unas aplicaciones con otras: .3. a Variantes: n capas Nos encontramos con esta variante cuando hay un servicio que cubre otro servicio.3.

3. El problema en este a a caso es el paso de par´metros. Java RMI. idea. ıo mediante llamadas a procedimientos remotos. Son ejemplos: DCOM. se desarroll´ el DCE (Distributed Computing Environment). o mediante objetos distribuidos. . Env´ de mensajes ıo Esta es una t´cnica de bajo nivel en la que el programador se encarga de gestionar e todos los detalles de la comunicaci´n (un ejemplo: sockets). Modelos de objetos distribuidos Est´n basados en DCE. . y la ventaja que aportan es que aprovechan la teca nolog´ ya existente y. DCOM Desarrollado por Microsoft. para objetos distribuidos. RPC.44 CAP´ ITULO 7. Se trata de que una aplicaci´n e o llama a un procedimiento de un proceso que est´ en otra m´quina. por ejemplo. o a objetos. Llamadas a procedimientos remotos Tambi´n denominada RPC (Remote Procedure Call). . que suele ser dependiente del lenguaje utilizado.3. es la evoluci´n del modelo COM (Component Object Moo del) integrado en OLE (Object Linking and Embedding)1 . y sus siglas responden a las iniciales de Distributed COM.3. se tienen llamadas a m´todos de ´stos y no a ıa e e procedimientos de librer´ algo que permite aprovechar las utilidades de la orientaci´n ıas. 7. Las aplicaciones que usan DCE RPC tienen un esquema: 7. CORBA. OBJETOS DISTRIBUIDOS Mediante lo que se conoce como env´ de mensajes.3. e . . Para solua cionarlo.2. Lo que se hizo fue aplicar la misma tecnolog´ la misma ıa. o 7. Ventajas Es utilizable desde cualquier lenguaje (siempre que ´ste tenga las capacidades nee cesarias.1.. que define los datos o independientemente del lenguaje mediante la NDR (Network Data Representation). al utilizar objetos. 1 Aunque tambi´n forma parte de ActiveX. .

de modo que se puede utilizar all´ donde haya una ıa ı m´quina virtual Java. 7.7. a a ∗ Gran facilidad de uso: los objetos remotos son muy f´ciles de crear y utilizar. Inconvenientes Su uso es complicado.4. Hacer disponibles las referencias a dichos objetos remotos. .1. a Ventajas Puede utilizarla cualquier lenguaje.4. Permanecer esperando a que llamen los clientes. a Pueden alojarse en cualquier plataforma (hay servicios corba para hasta una treintena de plataformas: Windows. grupo de empresas dedicado al desarrollo de est´ndares. 7.4. . no est´ ligado a una plataforma concreta. hay soporte para lenguajes desde los m´s antia guos (¡como cobol!) hasta los m´s modernos.. 2 Object Management Group. son las iniciales de Remote Method Invocation. ). a CORBA La Common Object Request Broker Arquitecture es la arquitectura m´s com´n a u 2 para los intermediarios en las peticiones de objetos. . Linux. o . que cuentan con facilidades para su manejo. JAVA RMI Inconvenientes Est´ restringido a la plataforma windows 32-bits. Est´ gestionado por el OMG . a Inconvenientes ◦ Est´ ligado a Java. a veces es m´s c´moda alguna de las anteriores soluciones a o naturales. a Java RMI 45 Desarrollado por los mismos creadores de Java. √ √ √ Java RMI Servidor Entre sus tareas se encuentran: Crear objetos remotos. Ventajas ∗ Utiliza tecnolog´ 100 % Java. esto es. sobre todo en a orientaci´n a objetos. .

4. hay que conocerlos. 7. public interface InterfazServidor extends Remote { public String Consulta (String Criterio) throws RemoteException.4.3.*. o El servidor ofrece unos servicios encarnados en los m´todos de un objeto remoto. de modo que se e especifican en un interfaz : import java.rmi. Llamar a m´todos de esos objetos remotos. 3 Creaci´n y ejecuci´n (cliente y servidor) o o (1) Definici´n del interfaz remoto. . } (2) Implementaci´n del interfaz. Clientes Deben poder: Obtener una referencia de un objeto remoto (en un determinado servidor). e Para poder usar esos m´todos. o (3) Compilaci´n de la clase Servidor. por supuesto.2. o (4) Crear STUB y SKELETON.46 CAP´ ITULO 7. Se lleva a cabo con la orden: $ rmic claseServidor 3 Ver transparencias. e El esquema es m´s o menos el siguiente: a Skeleton y Stub son sendos proxies que hacen que la comunicaci´n por la red entre o clientes y servidores sea transparente a ambos. OBJETOS DISTRIBUIDOS 7.

La ventaja que presenta es que es un lenguaje neutro (no es C. . (7) Registro de los objetos del Servidor.lookup para obtener la referencia del objeto remoto que quiere manejar. A la par existen “puentes” de comunicaci´n entre ´stos e IDL. ı.5. ni Java. intermediarios entre clientes y servidores. que a o e partir de una interfaz IDL obtiene una interfaz en el lenguaje destino: As´ la forma de crear los interfaces es independiente del lenguaje. que en su m´todo main e crea una instancia del servidor. o El constructor de la clase Cliente llama a Naming. CORBA 47 o El rmci genera dos clases: claseServidor STUB. que ha de ponerse a disposici´n del cliente.5.5. Es tan sencillo como: $ start rmiregistry (6) Creaci´n de los objetos del Servidor. El constructor de la clase Servidor llama a la funci´n Naming. lo que hace que no est´ ligado a ninguna plataforma. CORBA Definido por la OMG. ).7. (8) Implementaci´n de la clase Cliente. para crearo las de manera sencilla e independiente del lenguaje.1. . que son el contrato entre clientes y o servidores. . (2) ORB (Object Request Brokers): gestores de peticiones de objetos.class. que sirve para o llevar a cabo el registro. (5) Ejecutar el registro RMI. es en realidad una especificaci´n formal del OMA (Object o Management Arquitecture) al que las empresas se ajustan para fabricar los productos comerciales. (3) GIOP (General Inter-ORB Protocol): protocolo de comunicaci´n entre ORB’s. IDL IDL es un lenguaje de definici´n de interfaces. o 7. 7. Una vez “tra´ ıda”. compiladores IDL. y claseServidor SKELETON. o Para ello simplemente se ejecuta el archivo Servidor.rebind. e Los pilares fundamentales de corba son tres: (1) IDL (Interface Definition Language): lenguaje de definici´n de interfaces. se ejectua como si fuera local.

como para la plataforma en que est´ corriendo.2. a Son ejemplos: el Visibroker de Inprise (Delphi). . ).3.0. . Los orb de cada extremo pueden diferir en lenguaje y plataforma. Servicios CORBA Pertenecientes al oma. PX/SPX.48 CAP´ ITULO 7. lo ıan que habilita esto es el uso de un protocolo est´ndar como es GIOP. la implementaci´n GIOP para TCP/IP. Son a espec´ ıficos tanto para el lenguaje en que se codifica el servidor (o el cliente). a donde cualquier cliente puede ir a consultar. Java2 de Java. Los servicios corba son a su vez objetos corba que los proporcionan. a la que luego se le ha de dar una imo e o plementaci´n concreta dependiendo del protocolo de transporte (TCP/IP. se defini´ en la versi´n 2.5. 7. OBJETOS DISTRIBUIDOS 7.5. Uso de CORBA desde Java (Ejemplo) (1) Crear el interfaz IDL.5. Este servicio se estar´ ejecuo a tando en un lugar conocido en la red. o El est´ndar obliga a que como m´ a ınimo se haga una implementaci´n de IIOP (Internet o Inter-ORB Protocol).0. .4. Es una espeıa o o o cificaci´n gen´rica de c´mo conectar dos ORB’s. ORB Los ORB a˜aden una capa m´s a la comunicaci´n entre cliente y servidor.5. que ten´ que estar codificados en el mismo lenguaje (Java RMI). s´lo algunas implementaciones de corba los implementan.5. lo que los distingue de skeleton y stub. GIOP Este protocolo no exist´ en la versi´n 1. de modo que pueden ser usadas de modo sencillo por los clientes. . . o 7. proporn a o cionando m´s independencia de la plataforma y del lenguaje al mecanismo corba. 7. Eventos: para gestionar los distintos tipos de eventos que se puedan dar entre os objetos corba. Los clientes lo usan para obtener las referencias de los objetos remotos. Los o m´s comunes son: a Nombres: facilita la resoluci´n de referencias a objetos. a Su tarea es realizar el marshalling/unmarshalling de forma transparente para clientes y servidores.

e .java. En java2 se denomina tnameserver y generalmente corre en el puerto 900 de la m´quina.idl 49 Las opciones son para que no se use el preprocesador de C. que hace un cast a una referencia corba para e devolver un objeto remoto como un objeto Java. Esta orden crea una carpeta. No se llama a este m´todo. Esqueleto. Clases auxiliares Son dos: IConsultaHelper. sino que gestiona la llamada remota para llamar al proe cedimiento definido en el servidor. en la que se guardan varios ficheros: Interfaz en Java.java e IConsultaHolder. y la segunda controla el paso de par´metros in y out que existen en otros lenguajes como C++. que inicializa tambi´n su ORB y obtiene referencias de e los objetos remotos a trav´s del servidor de nombres. Se tienen dos clases en el archivo: 1. Stub del cliente Es la clase IConsultaStub. Clase ConsultaServant. 2. (5) Implementar el cliente. Clase ServidorConsulta. SvrConsultas. que implementa el interfaz.5.7. que nos permitir´ obtener las referencias a los a objetos que queramos. que registra el servidor. 1. a (4) Implementar el servidor. CORBA (2) Compilar el fichero IDL a nuestro lenguaje: $ idl2java -fno -cpp Consulta. Stub. La primera a contiene el m´todo narrow. que implementa el interfaz IConsulta. Dos archivos (clases) auxiliares. que sirve como base para la implementaci´n del servidor. Esqueleto del servidor Es la clase abstracta IConsultaImlBase. inicializa el ORB y espera las llamadas de los clientes. o 2. a (3) Activar el servicio de nombres. Contienen m´e todos est´ticos (que se pueden llamar sin crear una instancia). 3.

desconectar y m´s tarde reconectarse y volver a llamar a m´s procedimientos. o 7.6. no mantienen el estado entre conexiones. un usuario puede conectarse. Acercamiento de Java a CORBA Se produjo mediante dos acciones principales: La inclusi´n de un ORB en java2. es ı. esto es. Interfaces DCOM Tambi´n se basa en el concepto de los interfaces que luego son implementados. llamar a procedimientos del objeto. OBJETOS DISTRIBUIDOS 7. Existe un m´todo que proo e porciona estos n´meros garantizando que son unicos tanto en espacio (ya que utiliza la u ´ direcci´n IP ´ la direcci´n Ethernet para calcularlo) como en tiempo (utiliza tambi´n la o o o e fecha y hora de creaci´n). o Los problemas con que nos encontramos residen en que los objetos DCOM no son objetos al uso.6. y nada a a garantiza que la instancia del objeto sea la misma. (eso s´ ser´ de la misma clase).6. . Desarrollado por Microsoft.50 CAP´ ITULO 7. y siempre van a implementar uno denominado IUnknown. Los objetos DCOM implementan interfaces. e En DCOM. DCOM Es el principal competidor de CORBA. con todo lo que ello supone. destaca entre sus caracter´ ısticas la de ser independiente del lenguaje. a decir. → Release. Este interfaz tiene los m´todos: e → AddRef. o La implementaci´n de Java RMI sobre IIOP.5. → QueryInterface. los objetos se identifican por medio de un n´mero de 128 bits que se llama u GUID (Globally Unique Identifier ) ´ CLSID (Class ID).1. 7.

6. en distinto espacio de nombres. Cliente y servidor se hallan en m´quinas distintas. ıas (a) Servidores Locales. . Si en los dos anteriores se pod´ usar objetos ıan COM.2. por tanto.6. Servidores DCOM La clase IClassFactory permite crear instancias del tipo del objeto. Tanto las aplicaciones como los objetos internos (cuyas referencias se tienen en librer´ dll) corren en un mismo espacio de nombres. En este caso los objetos se buscan en un exe. DCOM 51 Los dos primeros se usan para saber cu´ntos clientes est´n accediendo al objeto (poseen a a referencia de ´l) en un determinado momento.7. aunque residan en la misma m´quina y mismo sistema a operativo. o una versi´n m´s sencilla de RPC. es una clase que hace la funci´n de “constructor”. La comunicaci´n se lleva a cabo gracias al LRPC (Lightweight RPC ). Acceso a un objeto DCOM Hay tres formas de acceder a un objeto DCOM: (a) Servidores Internos. 7. o El equivalente al registro de nombres de CORBA es el registro de Windows.3. El tercero comprueba qu´ otras interfaces e e implementa el objeto en cuesti´n. o a (a) Servidores Remotos. o 7. en este caso es obligado utilizar DCOM.6. utilizan a el protocolo RPC para comunicarse.

52 CAP´ ITULO 7. OBJETOS DISTRIBUIDOS .

. . . . . . . .1. . . . . . . e 3. . . . . . TADs . . . . . . . . . . . . . . . . . . Abstracci´n . . . .3. . . . . . . . . . . Modelado Estructural: Diagrama de clases . 3. . . . . . . . .5. 4. . Sobrecarga . . . . . . . . .4. . . . .2. . . . . . . . 5 5 5 5 6 6 6 7 9 9 11 11 11 11 15 15 16 16 17 18 18 19 23 25 25 26 26 28 28 28 30 33 . . . . . . . . . . . . . . .5. . .1. . . Objetos . . . . . . . 3. . . . . . . . . . . . . Ligadura . . .1. . . . . . . . . . .6. . . . . . . . . . . . o 2. . Objetivos de los paquetes . Criterios de Modularidad de Meyer . . . . . .6.1. . . . . . .3. . . . . . . . . . . . . . . . . . o 3. . . . . . . . . Tipificaci´n . . . . . . . . . . . o 1. . . . . . Definici´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1. . . . . 2. . . . . Programaci´n modular . . . . . . . . . . . . . . . . Polimorfismo . . . . . . . . . . o 1. . . . . . . Creaci´n de objetos . . . . . . . .2. . . . . . . . .4. .1. . . . . . . . . . Programaci´n Orientada a Objetos . Programaci´n estructurada . . .2. . . . . . . . . . . . . . . . . . . . . o 3. . . . . . .3. . . . . . . . . . . . . . . . . . . 3. Encapsulamiento . . . . . . . . . . . . . . . . Polimorfismo Universal Param´trico . . . . . . . . . . . . . Propiedades b´sicas de la Orientaci´n a Objetos a o 3. . . . . .´ Indice general 1. . . . . . Polimorfismo Universal de Inclusi´n . . . . . . . . .1. . . Clases . . . . . . . . . .4. .2. . . . . . . . . . . . . . . 37 5. Modularidad . .5. . . . . . . . . . . . . . . . . . . . . . . Herencia . . 3. . . . . . . . . . .3. . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. . . 1. 3. . . . . . . . . . . . . . Evoluci´n de los lenguajes de programaci´n o o 1.2. Elementos b´sicos de la Orientaci´n a o 2. . . Programaci´n no estructurada . . . . . . . . . . . . . . . . . . . .1. 3.6. . . . . . . . . . . . . . . . . o 3. . . . . . . Programaci´n procedimental . . . . . . . . .2. . . . . . . . . . Jerarqu´ . . . . . 3. . . . . . . . . . .2. .6. . . Tipificaci´n y ligadura . . . . Resumen . . . . . . . . . .3. . . . . . . o 1. . .2. . . . . . . Mecanismos Comunes . . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . .2. . .2. . . . . . . . . . a Objetos . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evoluci´n de los Lenguajes Orientados a Objetos o 5. . . . .2. .7. . . . . . . . .5. . . . . . . . o 3. o 3. . . . . . . . . UML 35 5. o 1. . . . . . . . . . . . . .5. . . . . . . . . . . . . . 3. . Coacci´n . . ıa 3. . .4. . . . . . . . . . . . . . . . . . . 38 53 . . . . . . . . Alternativas a la herencia: la Composici´n o 3. . . . . . . . . . . . . . .1. . . . . . Caracter´ ısticas principales . .4. . . . o 2. . . . . . . . .1. . . . . . . . . . . . . . 2. . . . . . . . . . . . . . . . . . . . . . . . .

. Patrones de Dise˜o . . . . . . . Objetos Distribuidos 7. . . . . . . . . . . . . . . . . . . . . . . . Servidores DCOM . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . .2. . 7. . . . . . . . . . . . . . . . . . . . . .2. . .2. . . . . Env´ de mensajes . . 41 41 41 41 42 43 43 44 44 44 45 45 46 46 47 47 48 48 48 48 50 50 50 51 51 . . . . . . . . . . . . . . . . . . . .2. . . . . . Interfaces DCOM . . . . .3. . . . . Aplicaciones Monol´ ıticas o Monocapa . . . Partes de una aplicaci´n . . . . . . . . . . . . . . . . .3. . . . Cliente/Servidor . . . . .5. . . . . . . . . . . . . . .3. . . . . . . . . 7. . Llamadas a procedimientos remotos . . . . . . .6. . . . . . . . . . . . . . . 39 6. . . . . . . . o 7. . . . . 7. Acceso a un objeto DCOM . . 7. . . . . . . . . . . DCOM . . . . . . . CORBA . . . . . . . . . . . . . . . 7. . . . . . . . .1. . . IDL . . . . . . . . . 7. . . . . .54 ´ INDICE GENERAL 6. . . . . . . . . .3. . . 7. . .1. . . .3. . . . . Clientes . . . . . . . . . Comunicaci´n entre aplicaciones . . . 7.1. . . .3. . . . . . . . . . . . . . . . . . . . .2. . . . . . 7.6. . . . . . . .5. .1. . . . . . . . . . . . . Acercamiento de Java a CORBA . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . .3. .4. . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . ORB .5.5. .2. . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uso de CORBA desde Java (Ejemplo) . . . . . . . . . . . . . . . . . Tres Capas . . . . . . . . . . . . . . . . . . . . 7. 7. . . . . . . . . . . . . . . Creaci´n y ejecuci´n (cliente y servidor) o o 7. . . . . . . . . . . . . . . . .2. .4. . . . . . . . . . . . . . . . . . .5. Tipos de Patrones . . . . . . . . . . . . . . Servidor . 40 n 7. . . . . . . . . . . . . . . . . . . . . . . 7. . . . 7. . .5. o 7. . . . 7. . Servicios CORBA . . . .3. . .2. . . . .2. . . . . . .2. Tipos de aplicaciones .5. . . 7. . . . . . ıo 7. . . . . 7. . . . .6. .3. . . . . .1. . Java RMI . . Patrones de Software 39 6. . . . . . . . . . Modelos de objetos distribuidos . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . 7.4. GIOP . 7. . . . . . .4. . . . . . . . . 7. . . . . . . . . .

Sign up to vote on this title
UsefulNot useful