Paradigma Orientado A Objetos

MODELOS DE DESARROLLO DE PROGRAMAS Y PROGRAMACON CONCURRENTE
PARADIGMA ORIENTADO A OBJETOS Disponible en: http://www.desy.de/gna/html/cc/Tutorial/Spanish/node6.htm
I) INTRODUCCION Actualmente una de las reas ms candentes en la industria y en el mbito acadmico es la orientacin a objetos. La orientacin a objetos promete mejoras de amplio alcance en la forma de diseo, desarrollo y mantenimiento del software ofreciendo una solucin a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del cdigo y reusabilidad, cdigo que es difcil de modificar, ciclos de desarrollo largos y tcnicas de codificacin no intuitivas. Un lenguaje orientado a objetos ataca estos problemas. Tiene tres caractersticas bsicas: a) debe estar basado en objetos b) basado en clases y c) capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera ms difcil de sortear es usualmente la herencia. El concepto de programacin orientada a objetos (OOP) no es nuevo, lenguajes clsicos como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolucin del problema se realiza en trminos de objetos, un lenguaje se dice que est basado en objetos si soporta objetos como una caracterstica fundamental del mismo. El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organizacin. Esta definicin especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto nmero de componentes bin estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organizacin jerrquica o de otro tipo.
-1Ao 2011
II) ESTRUCTURA DE UN OBJETO Un objeto puede considerarse como una especie de cpsula dividida en tres partes:
OBJETO
1 - RELACIONES 2 - PROPIEDADES 3 - METODOS
Propiedades Mtodos
Cada uno de estos componentes desempea un papel totalmente independiente: II.1) RELACIONES: Las relaciones permiten que el objeto se inserte en la organizacin y estn formadas esencialmente por punteros a otros objetos. Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organizacin. Las hay de dos tipos fundamentales: -Relaciones jerrquicas. Son esenciales para la existencia misma de la aplicacin porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organizacin en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos).
FIG. 2 ORG. JERARQUICA SIMPLE (Un hijo tiene slo un padre)
-2Ao 2011
FIG. 3 ORG. JERARQUICA COMPLEJA (un hijo puede tener varios padres)
Una organizacin jerrquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organizacin jerrquica compleja un hijo puede tener varios padres(F tiene a B y C como padres). -Relaciones semnticas. Se refieren a las relaciones que no tienen nada que ver con la organizacin de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en s mismos (de su significado) y no de su posicin en la organizacin. Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definicin de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organizacin jerrquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo. La raz del diccionario podra llamarse TEMAS. De ste trmino genrico descendern tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprender las ciencias biolgicas: Biologa y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las Matemticas, la Fsica, la Qumica y la Geologa. El tercero (hombre) comprender las ciencias humanas: la Geografa, la Historia, etc. Estableceremos la relacin trabaj entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabaj en ptica (vase la fig. 4). La relacin es, evidentemente, semntica, pues no establece ninguna connotacin jerrquica entre NEWTON y OPTICA y su interpretacin depende exclusivamente del significado de ambos objetos.
TEMAS
VIDA
MUNDO
HOMBRE
O
BIO MED MAT FIS QUIM GEOG HIST
Optica
No hay relacin jerrquica entre ptica y Newton
Newton
FIG. 4 TEMAS
La existencia de esta relacin nos permitir responder a preguntas como: Quin trabaj en ptica?- En qu trabaj Newton?- Quien trabaj en Fsica? Las dos primeras se deducen inmediatamente de la existencia de la relacin trabaj. Para la tercera observamos que si Newton trabaj en ptica automticamente sabemos que trabaj en Fsica, por ser ptica una rama de la Fsica (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera
-3Ao 2011
pregunta sin necesidad de establecer una relacin entre NEWTON y FISICA, apoyndonos slo en la relacin definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de informacin que tendremos que definir para todo el diccionario ser mnima.
II.1.2 Clasificacin de las relaciones II.1.2.a - Relacin De-La-Especie

Considrese que se ha escrito un programa para dibujar. Este programa debera permitir el dibujo de variados objetos tales como puntos, rectngulos, tringulos y muchos ms. Por cada objeto, se provee una definicin de clase. Por ejemplo, la clase Point define un punto por sus coordenadas: class Point { attributes: int x, y methods: setX(int newX) getX() setY(int newY) getY() } Se contina definiendo clases de programa de dibujo con una clase para describir crculos. Un crculo define un punto central y un radio: class Circle { attributes: int x, y, radius methods: setX(int newX) getX() setY(int newY) getY() setRadius(newRadius) getRadius() } Comparando ambas definiciones de clase, podemos observar lo siguiente :
Ambas clases tienen dos elementos de datos x e y. En la clase Point estos elementos describen la posicin del punto, en el caso de la clase Circle describen el centro del
-4Ao 2011
crculo. As, x e y tienen el mismo significado en ambas clases: Describen la posicin de su objeto asociado por medio de la definicin de un punto. Ambas clases ofrecen el mismo conjunto de mtodos para obtener y definir el valor de los dos elementos de datos x e y.
La clase Circle "aade'' un nuevo elemento de datos radius y sus correspondientes mtodos de acceso.
Conociendo las propiedades de la clase Point: podemos describir un crculo como un punto ms un radio ms mtodos para accederlo. As, un crculo es "de-la-especie" Point. Sin embargo, un crculo es algo ms "especializado". Ilustramos esto grficamente en la Figura 5.1.
Figura 5.1: Ilustracin de la relacin "de-la-especie". En sta y en las siguientes figuras, las clases se dibujan usando rectngulos. Su nombre siempre empieza con una letra mayscula. Las flechas indican la direccin de la relacin, de ah que se deba leer como "Circle es de-la-especie Point". II.1.2.b - Relacin Es-Un(a) La relacin anterior se usa al nivel de clase para describir las relaciones entre dos clases similares. Si creamos objetos de tales clases, nos referimos a su relacin como una relacin "esun(a)". Desde el momento que la clase Circle es de la especie de la clase Point, una instancia de Circle, digamos acircle, es un point. Consecuentemente, cada crculo se comporta como un punto. Por ejemplo, se puede mover puntos en la direccin x al alterar el valor de x. Similarmente, se mueven crculos en sta direccin al alterar su valor de x. La Figura 5.2 ilustra esta relacin. En sta y en las siguientes figuras, los objetos se dibujan usando rectngulos con las esquinas redondeadas. Su nombre consiste solamente de letras minsculas.
Figura 5.2: Ilustracin de la relacin "es-un(a)".
II.1.2.c - Relacin Parte-De Algunas veces se necesita poder construir objetos haciendo una combinacin de otros. Esto se sabe por la programacin procedimental, donde se tiene la estructura o registro para juntar variados tipos de datos.
-5Ao 2011
Regresemos al programa de dibujo. Ya se han creado varias clases para las figuras disponibles. Ahora se decide que se quiere tener una figura especial que representa un logotipo propio que consiste en un crculo y un tringulo. (Asumamos que ya se tiene definida un clase Triangle.) De este modo, el logo consiste en dos partes o, el crculo y el tringulo son parte-de logotipo: class Logo { attributes: Circle circle Triangle triangle methods: set(Point where) } Ilustramos esto con la Figura 5.3.
Figura 5.3: Ilustracin de la relacin "parte-de". II.1.2.d - Relacin Tiene-Un(a) Esta relacin es justamente la inversa de la relacin parte-de. Por lo tanto, podemos fcilmente aadir esta relacin a la ilustracin parte-de aadiendo flechas en la otra direccin (Figura 5.4).
Figura 5.4: Ilustracin de la relacin "tiene-un(a)".
-6Ao 2011
II.2) PROPIEDADES Todo objeto puede tener cierto nmero de propiedades, cada una de las cuales tendr, a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clsicas "variables" de la programacin estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los mtodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor nico o pueden contener un conjunto de valores ms o menos estructurados (matrices, vectores, listas, etc.). Adems, los valores pueden ser de cualquier tipo (numrico, alfabtico, etc.) si el sistema de programacin lo permite. Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes: -Propiedades propias. Estn formadas dentro de la cpsula del objeto. -Propiedades heredadas. Estn definidas en un objeto diferente, antepasado de ste (padre,"abuelo", etc.). A veces estas propiedades se llaman propiedad miembro porque el objeto las posee por el mero hecho de ser miembro de una clase. Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organizacin y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organizacin. II.3) METODOS Los mtodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarn incorporados en forma de programas (cdigo) que el objeto es capaz de ejecutar y que tambin pone a disposicin de sus descendientes a travs de la herencia. Los mtodos son una operacin que realiza acceso a los datos. Podemos definir mtodo como un programa procedimental o procedural escrito en cualquier lenguaje, que est asociado a un objeto determinado y cuya ejecucin slo puede desencadenarse a travs de un mensaje recibido por ste o por sus descendientes.
Objeto 1
Propiedades
Mensaje (invocacin de un mtodo)
Objeto 2
Propiedades
Mtodos
Mtodos
Son sinnimos de 'mtodo' todos aquellos trminos que se han aplicado tradicionalmente a los programas, como procedimiento, funcin, rutina, etc. Sin embargo, es conveniente utilizar el trmino 'mtodo' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la
-7Ao 2011
forma de invocarlo (nicamente a travs de un mensaje) y a su campo de accin, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos. Si los mtodos son programas, se deduce que podran tener argumentos, o parmetros. Puesto que los mtodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un mtodo de dos maneras diferentes: -Mtodos propios. Estn incluidos dentro de la cpsula del objeto. -Mtodos heredados. Estn definidos en un objeto diferente, antepasado de ste (padre,"abuelo", etc.). A veces estos mtodos se llaman mtodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase.
III - OBJETO (Resmen) Los objetos soportan una serie de caractersticas especficas de los mismos:

Se agrupan en grupos denominados clases Contienen datos internos que definen su estado actual. Soportan ocultamiento de datos. Pueden heredar propiedades de otros objetos. Pueden comunicarse con otros objetos enviando o pasando mensajes. Tienen mtodos que definen su comportamiento
Un objeto es una entidad lgica que contiene datos y un cdigo especial que indica como manipular los datos. El uso de un objeto impone a veces castigos al momento de la ejecucin que en ocasiones pueden degradar seriamente el diseo de un programa. Los objetos son construcciones de programacin que se obtienen a partir de entidades llamadas clases. El programador tiene la responsabilidad absoluta de crear clases propias, pero tambin puede tener acceso a las clases desarrolladas por otros. Ejemplo: diseo de un Objeto.
Class Nmina de Personal
class
nomina {nomina empleado;
Nombre Empleado 1
Salario
Objetos char nombre[30]; float salario; }; (nomina es una clase ) (empleado es un objeto)
Empleado 2 .......... Empleado n
Los objetos son ejemplos de clases.
-8Ao 2011
IV - CONCEPTO DE CLASE Cada objeto es un ejemplar de una clase a la que pertenece. Todos los ejemplares de la misma clase tienen el mismo comportamiento (es decir invocan al mismo mtodo) como respuesta a una solicitud similar.
Clase A
Objeto 1
Objeto 2
Objeto n
Una clase es un tipo especial de datos, y esta orientado a creacin de objetos y que consta de unos miembros que pueden ser todas o funciones privadas o pblicas. Una clase es un tipo de dato que contiene uno o ms elementos llamados dato miembro, y cero, una o ms funciones que manipulan esos datos (llamados funcin miembro). Una clase se puede definir con una estructura (struct), una unin (unin) o una clase (class). La sintaxis de una clase es: class nombre_clase { miembro_1; //lista de datos miembros miembro_2 miembro_3 funcion_miembro_1( ); // funciones miembro conocidas funcion_miembro_2 ( ); // funciones como mtodos
-9Ao 2011
IV.1 - Identificadores de diseo de una clase
Para usar una clase, primero hay que declararla, como se hace en el caso de las estructuras. La declaracin de una clase puede aparecer slo una vez en un programa, tal y como las estructuras. Esta es una declaracin de una clase simple: class counter { long count; Variable miembro de la clase public: void SetCount(long); long GetValue( ); };
-La palabra clave class introduce una declaracin de clase. -Despus aparece el nombre de la clase. -Las clases contienen no slo declaraciones de variables, sino tambin definiciones de funciones completas. -Las funciones contenidas en clases pueden ser tan largas y complejas como uno desee que lo sean. -Se considera que las variables declaradas dentro de una clase pertenecen a esa clase. En ciertas circunstancias, las variables pueden compartirse entre las diferentes instancias de una clase. -Existe garanta de que los identificadores de variables y funciones contenidos en una clase no chocan con los identificadores que se usan en otras. Bsicamente una clase es un mundo con identificadores propios nicos. IV.2- Cuerpo de una Clase La variable count se define dentro del cuerpo de la clase. Por lo tanto, count recibe el nombre de variable miembro de la clase.
-10Ao 2011
Cualquier variable definida en una clase tiene campo de accin. El campo de accin de la clase no est disponible, es decir, que este punto de declaracin es una variable final de la declaracin de la clase. Es un error intentar el acceso a una variable miembro despus de la declaracin de la clase, como se puede apreciar en el cdigo siguiente: class counter { long count; public: count = 3; //error: count no se encuentra definida aqu. IV.3- Uso de una Clase Para usar una clase se debe definir un objeto con ella. Las variables de una clase se definen tan solo como variables de tipo estructura o variables escalares. Para definir la variable de la clase people de tipo counter, se utiliza esta notacin: Counter people Las variables instanciadas a partir de clases son los objetos. En general, es imposible usar una clase directamente. Las contadas excepciones a esta regla se ilustran ms adelante. Para el objeto people, esta es la forma en que lo podra utilizar un programa: Void main ( ) { counter people; //inicializar el objeto people. SetValue(0); // verificar que se borre long value = people.GetValue( ); }
Una clase es un tipo especial de datos, y esta orientada a la creacin de objetos y que consta de unos miembros que pueden ser datos o funciones privadas o publicas.
-11Ao 2011
IV.4- Componentes de una Clase Para poder definir una clase se debe tomar en cuenta que consta de dos partes: una declaracin y una implementacin.
. La declaracin lista los miembros de la clase. . La implementacin o cuerpo define las funciones de la clase.
class nomina {nomina empleado; Declaracin de una clase
char nombre[30]; float salario; }; (nomina es una clase ) (empleado es un objeto) .. class contador{ long cuenta; public: void leervalor(long); long obtenervalor( ); }; ..
Funciones miembro de la clase
Implementacin de una clase void contador::leerValor(long valor) { cuenta = valor, } long contador::obtenerValor( ) { return cuenta;} }
-12Ao 2011
V- ENCAPSULAMIENTO Y OCULTACIN Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre s, como si estuvieran encerrados conjuntamente en una cpsula. Esta propiedad (encapsulamiento), es una de las caractersticas fundamentales en la OOP. Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cmo est distribuida la informacin o qu informacin hay disponible. Esta propiedad de los objetos se denomina ocultacin de la informacin. Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si as fuera no se podra hacer gran cosa con l. Lo que sucede es que las peticiones de informacin a un objeto, deben realizarse a travs de mensajes dirigidos a l, con la orden de realizar la operacin pertinente. La respuesta a estas rdenes ser la informacin requerida, siempre que el objeto considere que quien enva el mensaje est autorizado para obtenerla. El hecho de que cada objeto sea una cpsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organizacin, o incluso a otra organizacin totalmente diferente que precise de l. Si el objeto ha sido bien construido, sus mtodos seguirn funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilizacin de programas. VI- ORGANIZACIN JERARQUICA DE LOS OBJETOS En principio, los objetos forman siempre una organizacin jerrquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo. Existen varios tipos de jerarquas: sern simples cuando su estructura pueda ser representada por medio de un "rbol". En otros casos puede ser ms compleja. En cualquier caso, sea la estructura simple o compleja, podrn distinguirse en ella tres niveles de objetos. -La raz de la jerarqua. Se trata de un objeto nico y especial. Este se caracterza por estar en el nivel ms alto de la estructura y suele recibir un nombre muy genrico, que indica su categora especial, como por ejemplo objeto madre, Raz o Entidad. -Los objetos intermedios. Son aquellos que descienden directamente de la raz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, segn la aplicacin. Normalmente reciben nombres genricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.
-13Ao 2011
-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o items porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.
VII- POLIMORFSMO Una de las caractersticas fundamentales de la OOP es el polimorfsmo, que no es otra cosa que la posibilidad de construir varios mtodos con el mismo nombre, pero con relacin a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibiran el mismo mensaje global pero responderan a l de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significara suma, mientras que para un objeto STRING significara concatenacin ("pegar" strings uno seguido al otro) VII.1) Demonios Es un tipo especial de mtodos, relativamente poco frecuente en los sistemas de OOP, que se activa automticamente cuando sucede algo especial. Es decir, es un programa, como los mtodos ordinarios, pero se diferencia de estos porque su ejecucin no se activa con un mensaje, sino que se desencadena automticamente cuando ocurre un suceso determinado: la asignacin de un valor a una propiedad de un objeto, la lectura de un valor determinado, etc. Los demonios, cuando existen, se diferencian de otros mtodos por que no son heredables y porque a veces estn ligados a una de las propiedades de un objeto, mas que al objeto entero.
VIII - HERENCIA Con la herencia podemos hacer uso de las relaciones de-la-especie y es-un(a). Como se describi anteriormente, las clases que son de-la-especie de otra clase comparten propiedades de esta ltima. En nuestro ejemplo con el punto y el crculo, podemos definir un crculo, el cul hereda de punto:
class Circle inherits from Point { atrributes: int radius methods: setRadius(int newRadius) getRadius() }
-14Ao 2011
La clase Circle hereda todos los elementos de datos y mtodos de la clase Point. No hay necesidad de definirlos dos veces: Solamente usamos los ya existentes (y familiares) datos y definiciones de mtodos.
Al nivel de objeto ahora podemos usar un crculo justamente como habramos usado un punto, debido a que un crculo es-un(a) punto. Por ejemplo, podemos definir un objeto crculo (acircle) y establecer sus coordenadas del punto central:
Circle acircle acircle.setX(1) acircle.setY(2) acircle.setRadius(3) /* Aadido por Circle */ /* Heredado de Point */
"Es-un(a)" tambin implica que podemos usar un crculo en cualquier circunstancia donde se pueda usar un punto. Por ejemplo, se puede escribir una funcin o un mtodo, digamos move(), el(la) cul debe mover un punto en la direccin x:
move(Point apoint, int deltax) { apoint.setX(apoint.getX() + deltax) }
Debido a que crculo hereda de punto, se puede usar esta funcin con un argumento crculo para mover su punto central y, a partir de ah, todo el crculo :
Circle acircle ... move(acircle, 10) /* Mover el crculo al mover */ /* su punto central */
Tratemos de formalizar el trmino "herencia" : Definicin (Herencia) Herencia es el mecanismo que permite que un clase A herede propiedades de una clase B. Decimos "A hereda de B". Objetos de la clase A tienen as acceso a los atributos y mtodos de la clase B sin necesidad de redefinirlos. La siguiente definicin describe dos trminos con los que podemos hacer referencia a las clases involucradas cuando se usa la herencia. Definicin (Superclase/Subclase) Si la clase A hereda de la clase B, entonces B es la superclase de A. A es subclase de B. Los objetos de una subclase pueden ser usados en las circunstancias donde son usados los objetos de la superclase correspondiente. Esto se debe al hecho que los objetos de la subclase comparten el mismo comportamiento que los objetos de la superclase. En la literatura tambin se pueden encontrar otros trminos para "superclase" y para "subclase". Las superclases tambin son llamadas clases padres. Las subclases pueden ser llamadas tambin clases hijas o simplemente clases derivadas.
-15Ao 2011
Por supuesto, tambin se puede heredar de una subclase, haciendo que esta clase sea la superclase de la nueva subclase. Esto conduce a una jerarqua de relaciones superclase/subclase. Si se dibuja esta jerarqua, se obtiene una grfica de herencia. Un esquema comn consiste en usar flechas para indicar la relacin de herencia entre clases u objetos. En nuestros ejemplos hemos usado "hereda-de". Consecuentemente, la flecha empieza desde la subclase hacia la superclase, como se ilustra en la Figura 5.5.
Figura 5.5: Una grfica de herencia sencilla.
En la literatura tambin se puede encontrar ilustraciones donde las flechas se dibujan del modo contrario. La direccin en la que se usan las flechas dependen de como el autor correspondiente las haya decidido entender. De cualquier manera, en este apunte, las flechas siempre apuntan hacia la superclase. En las secciones siguientes, las flechas indican "hereda-de". VII .1 - Herencia Mltiple Un mecanismo importante de orientacin a objetos es la herencia mltiple. La herencia mltiple no significa que mltiples subclases compartan la misma superclase. Tampoco significa que una subclase herede de una clase que es a su vez subclase de otra clase. La herencia mltiple significa que una subclase puede tener ms de una superclase. Esto permite que la subclase herede propiedades de ms de una superclase y mezclar- sus propiedades. Considrese por ejemplo nuevamente nuestro programa de dibujo. Suponiendo que ya tenemos una clase String que nos permite el manejo adecuado de texto. Podra tener, por ejemplo, un mtodo append para aadir otro texto. En este programa, nos gustara usar esta clase para aadir texto a los objetos que se pudieran dibujar. Tambin sera bueno usar rutinas ya existentes tales como move() para mover el texto a donde fuera necesario.
-16Ao 2011
En consecuencia, es razonable permitir que un texto para dibujarse tenga un punto que defina su localizacin dentro del rea de dibujo. Por lo tanto derivamos una nueva clase DrawableString que hereda propiedades de Point y de String como se ilustra en la Figura 5.6.
Figura 5.6: String.
Derivar un string desplegable que herede propiedades de Point y de
En nuestro pseudo lenguaje, escribimos esto, simplemente separando las diferentes superclases con comas :
class DrawableString inherits from Point, String { attributes: /* Todos heredados de superclases */ methods: /* Todos heredados de superclases */ }
Podemos usar objetos de la clase DrawableString como ambos: puntos y strings.
Debido a que drawablestring es-un(a) point podemos mover dichos objetos:
DrawableString dstring ... move(dstring, 10) ...
Desde el momento que son string, podemos aadirles otro texto: dstring.append("La flores color azul ...") Podemos definir la herencia mltiple : Definicin (Herencia Mltiple) Si la clase A hereda de ms de una clase, p.ej. A hereda de B1, B2, ..., Bn, hablamos de herencia mltiple. Esto puede presentar conflictos de nomenclatura en A si al menos dos de sus superclases definen propiedades con el mismo nombre. La definicin de arriba presenta conflictos de nomenclatura los cules ocurren si ms de una superclase de una subclase usan el mismo nombre para ambos, atributos o mtodos. Por ejemplo, supongamos que la clase String define un mtodo setX() que
-17Ao 2011
pone el string en una secuencia de "X" caracteres. Se produce la pregunta Que debera ser heredado por DrawableString? La versin de Point, de String o ninguna de las dos? Estos conflictos pueden ser resueltos de al menos dos maneras :

El orden en el cul las superclases son provistas, definen que propiedad ser accesible por el nombre causante del conflicto. Los otros quedarn "escondidos". Las subclases deben resolver el conflicto proveyendo una propiedad con el nombre y definiendo como usar los de sus superclases.
La primera solucin no es muy conveniente ya que presentan consecuencias implcitas dependiendo del orden en el cul las clases heredan unas de otras. Para el segundo caso, las subclases deben redefinir explcitamente las propiedades que estn involucradas en conflictos de nomenclatura. Un tipo especial de conflicto de nomenclatura se presenta si una clase D hereda en forma mltiple de las superclases B y C que a su vez son derivadas de una superclase A. Esto conduce a una grfica de herencia como se muestra en la Figura 5.7.
Figura 5.7: Un conflicto de nomenclatura presentado por una superclase compartida por superclases usadas en herencia mltiple.
Cabe la pregunta acerca de que propiedades hereda realmente la clase D de sus superclases B y C. Algunos lenguajes de programacin existentes resuelven esta grfica de herencia especial derivando D con

las propiedades de A ms las propiedades de B y C sin las propiedades que han heredado de A.
Consecuentemente, D no puede presentar conflictos de nomenclatura con los nombres en la clase A. Sin embargo, si B y C aaden propiedades con el mismo nombre, D entra en un conflicto de nomenclatura.
-18Ao 2011
Otra posible solucin es que D herede de ambas trayectorias de herencia. En esta solucin, D tiene dos copias de las propiedades de A: una heredada de B y otra de C. Aunque la herencia mltiple es un poderoso mecanismo en orientacin a objetos, los problemas que se presentan con los conflictos de nomenclatura ha llevado a varios autores a "condenarla". Debido a que los resultados de la herencia mltiple siempre puede ser lograda usando herencia simple, algunos lenguajes orientados a objetos no permiten siquiera su uso. Sin embargo, usada con cuidado, bajo algunas condiciones la herencia mltiple provee una manera eficiente y elegante de formular cosas.
VIII - BENEFICIOS Y PROBLEMAS QUE SE OBTIENEN DEL DESARROLLO CON OOP
VIII.1- REUTILIZACION DE CODIGO
Da a da los costos del Hardware decrecen. As surgen nuevas reas de aplicacin cotidianamente: procesamiento de imgenes y sonido, bases de datos multimediales, automatizacin de oficinas, ambientes de ingeniera de software, etc. An en las aplicaciones tradicionales encontramos que definir interfases hombremquina "a-la-Windows" suele ser bastante conveniente. Lamentablemente, los costos de produccin de software siguen aumentando; el mantenimiento y la modificacin de sistemas complejos suele ser una tarea trabajosa; cada aplicacin, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc. Todos estos problemas an no han sido solucionados en forma completa. Pero como los objetos son portables (tericamente) mientras que la herencia permite la reusabilidad del cdigo orientado a objetos, es ms sencillo modificar cdigo existente porque los objetos no interaactan excepto a travs de mensajes; en consecuencia un cambio en la codificacin de un objeto no afectar la operacin con otro objeto siempre que los mtodos respectivos permanezcan intactos. La introduccin de tecnologa de objetos como una herramienta conceptual para analizar, disear e implementar aplicaciones permite obtener aplicaciones ms modificables, fcilmente extendibles y a partir de componentes reusables. Esta reusabilidad del cdigo disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea ms intuitivo porque la gente piensa naturalmente en trminos de objetos ms que en trminos de algoritmos de software.
VIII.2 - Problemas derivados de la utilizacin de OOP en la actualidad Un sistema orientado a objetos, por lo visto, puede parecer un paraso virtual. El problema sin embargo surge en la implementacin de tal sistema. Muchas compaas oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es
-19Ao 2011
ajena a los programadores actuales. Especficamente los siguientes temas suelen aparecer repetidamente: a) Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma nica. Involucra la conceptualizacin de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicacin entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que estn escritos los programas orientados a objetos actualmente; al hacer la transicin a un sistema orientado a objetos la mayora de los programadores deben capacitarse nuevamente antes de poder usarlo. b) Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la prctica existen muchas dependencias. Muchos lenguajes orientados a objetos estn compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementacin de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia mltiple mientras que SmallTalk no lo soporta; en consecuencia la eleccin de un lenguaje tiene ramificaciones de diseo muy importantes. c) Determinacin de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definicin de las clases es ms un arte que una ciencia. Si bien hay muchas jerarquas de clase predefinidas usualmente se deben crear clases especficas para la aplicacin que se este desarrollando. Luego, en 6 meses 1 ao se da cuenta que las clases que se establecieron no son posibles; en ese caso ser necesario reestructurar la jerarqua de clases devastando totalmente la planificacin original. d) Performance. En un sistema donde todo es un objeto y toda interaccin es a travs de mensajes, el trfico de mensajes afecta la performance. A medida que la tecnologa avanza y la velocidad de microprocesamiento, potencia y tamao de la memoria aumentan, la situacin mejorar; pero en la situacin actual, un diseo de una aplicacin orientada a objetos que no tiene en cuenta la performance no ser viable comercialmente. Idealmente, habra una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Debera existir una metodologa fcil de aprender e independiente del lenguaje, y fcil de reestructurar que no drene la performance del sistema.
-20Ao 2011

Paradigma Orientado A Objetos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Paradigma Orientado A Objetos

Transféré par

Droits d'auteur :

Formats disponibles

MODELOS DE DESARROLLO DE PROGRAMAS Y PROGRAMACON CONCURRENTE