Java – Paso a paso Tema 3

Written by lopezatienza on 02/07/2009 – 13:59 -

TEMA3. PARADIGMA ORIENTADO A OBJETOS

En esta Unidad Didáctica se pretende dar unos ciertos conocimientos generales sobre el paradigma orientado a objetos. Veremos los orígenes del paradigma, las características fundamentales y estudiaremos los aspectos más importantes de la orientación a objetos, intentando en todo momento utilizar ejemplos cotidianos y sencillos de la vida real para poder asimilar los conceptos, que nos servirán cuando empecemos a ver el lenguaje de programación Java.

1. Orígenes del paradigma OO
2. La familia Orientada a Objetos
3. ¿Qué significa orientado a objetos?
4. Principales ventajas de la POO
5. Clases y objetos
6. Abstracción
7. Encapsulación
8. Herencia
9. Polimorfismo
10. Diferencias con la programación estructurada

1. Orígenes del paradigma OO

El modelo orientado a objetos es relativamente antiguo. El germen nació con el lenguaje Simula, presentado en Oslo en 1967, cuyo objetivo era realizar un lenguaje de programación que permitiera la simulación de procesos paralelos. Con él aparece la idea de objeto como eje central del paradigma, asociando datos y procesos en una misma entidad.

Las ideas de Simula fueron reutilizadas y desarrolladas ampliamente por SMALLTALK, convirtiéndose en el lenguaje paradigmático por excelencia de la programación orientada a objetos. Fue diseñado en el Centro de Investigación de Xerox (Palo Alto, USA) a mediados de la década de los 70, con el fin de facilitar al usuario un sistema potente con una interfaz ágil, para lo que generó un entorno gráfico de sistemas multiventana con pantalla “bitmap”. Fue utilizado con gran éxito en la primera estación
gráfica de Xerox Parc (antecesor del Macintosh).

Actualmente, SMALLTALK se usa con fines pedagógicos como lenguaje puramente académico, siendo al paradigma orientado a objetos lo que en otro tiempo fue PASCAL al paradigma imperativo estructurado.

Con la aparición de las máquinas más potentes, fueron surgiendo nuevos lenguajes que iban incorporando el nuevo paradigma. Unos son extensiones de lenguajes diseñados como imperativos, como C++, Object LISP, Object PASCAL, Oberon (Modula orientado a objetos), no considerados puramente orientados a objetos pero que incorporan sus características más importantes. Otros nacen con el nuevo
modelo incorporado, ADA, EIFELL, JAVA, ACTOR, etc..

1.1 Evolución histórica del diseño del software

Antes de los años 60, el diseño y la programación de aplicaciones era considerado como un arte, no había método para el diseño ni la implementación de software, no había medios para el mantenimiento de los programas, de manera que si algo iba mal, era mejor sustituirlo que revisarlo. Por esta razón, la mayoría del software escrito en esta época tuvo que ser posteriormente reescrito. Esto desembocó en una conocida crisis del software.

En los años 60 surge la programación procedural, basada en procedimientos, que consiste en describir etapa a etapa el modelo de construir la solución de un problema y cuyas características más importantes consisten en el aumento de la legibilidad de programas, bajar los costes de mantenimiento y acelerar el proceso de desarrollo. Aparece también la técnica de programación estructurada que pone límites al programador con el uso de estructuras de control de flujo y estructuras de datos englobadas dentro de los propios lenguajes de programación, como una primera
aproximación de la abstracción de datos. Esta idea es incorporada y desarrollada por el paradigma orientado a objetos, de manera que actualmente la metodología de programación reconoce la necesidad de la abstracción de datos para diferenciar las especificaciones de su implementación y su representación interna.

La aparición en esta época de la programación modular ayuda a la producción de software, dividiendo la construcción de programas en módulos que pueden ser reutilizados en otras aplicaciones, idea igualmente incorporada a la OO, e introduciendo por primera vez el concepto de Tipo Abstracto de datos. Los datos empiezan a tener un papel importante.

A medida que el tiempo transcurría, los proyectos iban creciendo de tamaño y abarcaban nuevos y distintos campos, a la vez que eran realizados por un equipo más grande de personas. Curiosamente, se observó que cuanto mayor era el equipo de desarrollo menor era el rendimiento individual por la cantidad de esfuerzo que había que invertir en coordinación.

En este contexto, nace la POO con la idea de que el trabajo pueda ser dividido de forma coherente en pequeñas unidades independientes y de forma que la necesidad de coordinación se redujera al mínimo. Lo que se destaca, es que el trabajo del diseñador no es construir todos los componentes.

La POO divide a la comunidad de programadores en dos grupos:

- Productores de componentes. Son equipos que crean componentes, los someten a pruebas de depuración y proporcionan una interfaz de comunicación de manera que el producto llega al usuario en perfecto estado para su uso. La interfaz suministrada impide conocer el interior del componente, lo cual permite que los cambios internos que sufran no afecten a los consumidores de dichas componentes.

- Consumidores de componentes. La misión del consumidor de componentes (programador) es conocer los distintos componentes que existen en el mercado y usarlos convenientemente para conseguir el objeto deseado.

Como curiosidad, el paradigma de programación más actual, es la Programación Orientada a Aspectos. Es una de las últimas ideas en Informática y puede ayudar a traspasar la barrera de complejidad de las aplicaciones cuando se tratan ciertos “aspectos” del sistema como la seguridad, el control de errores y las transacciones.

2. La familia Orientada a Objetos

Los conceptos de la filosofía orientada a objetos no sólo alcanzan al contexto de la programación, dando lugar a los siguientes lenguajes, Smalltalk, Eifell, Java, C++, C# entre otros, sino que se han extendido a todos los ámbitos que integran el desarrollo de software.

En el terreno de análisis y diseño de aplicaciones, en la década de los años 80, surgieron distintas metodologías (las consideradas clásicas o de “primera generación”), por ejemplo: OOSD, OMT y JSD.

Posteriormente, ya en la década de los años 90, comenzaron a aflorar nuevas metodologías de desarrollo orientado a objetos, catalogadas como de “segunda generación”, de las que forman parte FUSION, OOA/D o MEDEA. En esta segunda generación se aprovechan las técnicas y procedimientos de las primeras: fichas CRC, modelo de clases de OMT, para generar metodologías más completas donde se incorporan además métricas y lenguajes formales de especificación.

Podría hablarse de una tercera generación, aparecida en la segunda mitad de los años 90, que se caracteriza por la integración de varios modelos existentes, Booch, Rumbaugh y Jacobson, derivando en UML (Lenguaje Unificado de Modelado), metodología establecidad como estándar en 1997 y adoptada en Métrica 3.

Actualmente, se realiza un esfuerzo de unificación que actúa principalmente sobre las notaciones de las técnicas usadas para el modelado orientado a objetos, ganando espacio lo que se denomina “técnicas de desarrollo ágil”, en un intento de simplificar la gran complejidad y diversidad de metodologías existentes. En esta línea está el método XP de Programación extrema, DSDM.

En el entorno de la arquitectura de sistemas de información y con el objetivo de facilitar el desarrollo de sistemas basados en arquitectura multinivel, aparecen estándares como CORBA para el desarrollo de sistemas de objetos distribuidos, J2EE propuesta de Sun para facilitar el diseño, desarrollo, ensamblaje, distribución y despliegue de sistemas distribuidos multinivel basado en componentes, o por último, DCOM de Microsoft que soporta comunicaciones entre objetos en diferentes ordenadores a través de redes de área local, banda ancha y a través de Internet.

Las BDOO (base de datos orientadas a objetos) representan el siguiente paso en la evolución de los sistemas de gestión de bases de datos para soportar el análisis, el diseño y la programación orientada a objetos. Las BDOO almacenan y manejan información que puede ser representada mediante objetos que proporcionan una estructura flexible con un modo de acceso rápido, con gran capacidad de modificación, permitiendo el desarrollo y mantenimiento de aplicaciones complejas ya que se puede utilizar un mismo modelo conceptual y así aplicarlo al análisis, diseño y programación, lo cual reduce el problema entre los diferentes modelos utilizados a través del ciclo de vida y disminuye considerablemente el costo de la aplicación.

En este contexto, existen extensiones de las relacionales como Ingres u Oracle y nuevos sistemas que nacen con los conceptos de la orientación a objetos incorporados como: Object Store, Versant, Objectivity o Genstone.

El modelo orientado a objetos también se extiende en el campo de los sistemas operativos dando lugar a interfaces como X/Windows, Motif o AWT y a sistemas completos, por ejemplo Next, Oberon, SCOUT o Nemesis.

3. ¿Qué significa orientado a objetos?

La aproximación orientada a objetos se caracteriza por la idea central, el objeto.
Un objeto es un concepto que asocia datos y procesos a una misma entidad, manteniendo una fuerte relación entre las estructuras de datos y los comportamientos en respuesta a mensajes, dejando visible sólo la interfaz de comunicación con el exterior.

De esta forma, el software se organiza como una colección de objetos que representan abstracciones del mundo real. Podemos decir que todo lo que nos rodea es un objeto (cada mesa, cada compañero, cada monitor, ...)

La esencia del desarrollo orientado a objetos reside en:

- La identificación y la organización de entidades en el dominio de la aplicación y no de la representación final en un lenguaje de programación.
- Es un proceso intelectual independiente de cualquier lenguaje.
- Se atienden temas conceptuales de primer nivel, no implementaciones que corresponden a un nivel inferior.
- El paradigma es aplicable a todas las fases y elementos que forman parte de la ingeniería del software: análisis, diseño, programación y bases de datos.

Como consecuencia, con la puesta en práctica de esta forma de pensar:

- Existe la posibilidad de representar directamente las entidades del mundo real en los escenarios informáticos, sin necesidad de deformarlas.
- Se facilita enormemente la reutilización y modificabilidad del software a partir.
- Es posible trabajar con entornos de desarrollo más potentes.
- Se puede trabajar en equipo, desarrollando en paralelo módulos para una aplicación con un esfuerzo mínimo en coordinación.

Por lo tanto, el modelo orientado a objetos contribuye al diseño de algoritmos con una aportación importante, en cuanto a la abstracción, generalización e interacción, y en cuanto a la sencillez de los procedimientos de adaptación y de extensión de software que permite.

Entre las razones que hacen tan atractiva la orientación a objetos figuran:

- La relativa cercanía de sus conceptos a las entidades que aparecen en el mundo real.
- La simplicidad del modelo, que emplea los mismos elementos fundamentales para expresar de manera uniforme el análisis, el diseño y la implementación de un sistema.
- La gran capacidad de adaptación e integración de sus modelos, que facilita la reutilización de modificaciones, incluso durante el proceso de desarrollo, y el mantenimiento.
- La posibilidad de aumentar las oportunidades de reutilización de componentes de software en proyectos distintos.

Existen una serie de pasos que sirven de guía a la hora de modelar un sistema empleando orientación a objetos:

1. Identificar los objetos que intervienen en él.
2. Agrupar en clases a todos aquellos objetos que tengan características y comportamiento comunes.
3. Identificar los datos y operaciones de cada una de las clases.
4. Identificar las relaciones que puedan existir entre las clases.

4. Principales ventajas de la POO

La programación orientada a objetos presenta ciertas características que la hacen destacar y al mismo tiempo la diferencian de la programación estructurada o modular, alguna de las cuales se describen a continuación:

- Protección de la información

El encapsulamiento de datos y procedimientos junto con unos niveles de acceso a la información forman unos límites que proporcionan una gran protección a la información contenida en el objeto.

- Rápido desarrollo

La posibilidad de volver a usar objetos (reutilización objetos) ya definidos y probados en otros programas, disponibles en librerías, permite que el desarrollo de programas se realice con gran rapidez. El funcionamiento es similar al uso de librerías de módulos en la programación estructurada y modular, con la ventaja de que los objetos tienen toda la información referente a los datos y los
procedimientos de una forma conjunta y con un comportamiento plenamente conocido.

- Fácil mantenimiento

En el caso de una modificación o mejora de una aplicación desarrollada con objetos, las características de la programación orientada a objetos, permiten que se realice con una gran facilidad, pues se reduce a modificar los componentes de algunos objetos o a crear nuevos objetos aprovechando los ya existentes, haciendo que hereden sus características.

- Un modelo de objetos es más cercano a la realidad que un modelo funcional.

- El modelo orientado a objetos facilita la integridad de módulos que han sido realizados por separado para no correr riesgos en el manejo de los datos.

5. Clases y objetos

En la vida cotidiana lo que los humanos percibimos desde niños del mundo exterior e incluso del mundo interior son objetos (el juguete de mi amigo, la mesa del profesor, el gracioso perro del vecino, mi nombre, etc.) pero en realidad hemos particularizado una determinada clase de objetos desde nuestro punto de vista (un juguete, un mueble, un animal, ...)

La programación orientada a objetos es un método de implementación en el que los programas se organizan como colecciones de objetos, cada uno de los cuales representa una instancia de una clase, y cuyas clases son miembros de una jerarquía de clases unidas mediante relaciones de herencias.

Objeto

Elementos fundamentales en una programación orientada a objetos con propiedades y características propias o particulares, y un conjunto de acciones con capacidad de ser ejecutadas como respuesta a unos eventos o sucesos que se originan en otros objetos o en el propio entorno. Es importante destacar que aunque cada objeto tenga propiedades distintas al resto, pueden compartir un conjunto de atributos en común si pertenecen a la misma clase o heredan dichos atributos de otras clases (herencia).

Un objeto es una particularización o instancia de una clase, siendo por tanto un concepto físico y concreto que tiene una existencia real y determinada. Los objetos, mediante los procedimientos definidos en la clase a la que pertenecen, pueden acceder a sus datos, que pueden estar ocultos para los demás objetos, dotando, de esta forma, de una gran protección a la información contenida en dicho objeto.

Los objetos son activados en los programas por mensajes que son llamadas a procedimientos que dicho objeto tienen incluidos en su clase.

Clases

Los objetos son instancias de las clases, que actúan como los tipos de datos que definen de forma abstracta un conjunto de valores, siendo las variables (en este caso instancias) las que realmente se manejan en un programa.

Una clase es una generalización de un tipo determinado de objetos, siendo por tanto un concepto abstracto que permite la comprensión de las propiedades o características y de las operaciones o procedimientos que se pueden realizar con dichas operaciones.

Toda clase se caracteriza por:

a) Un identificador, que es un nombre o etiqueta que se da a la clase para poder especificar la clase a la que pertenecen los objetos.

b) Unos componentes o miembros de la clase que son:

a. Atributos o propiedades, que conforman la estructura de datos que los objetos van a utilizar asignándoles unos valores que permitan diferenciarlos unos de otros.
b. Procedimientos o métodos, que conforman las operaciones que se pueden efectuar con los datos y que son utilizables por todos los objetos pertenecientes a la clase.

c) Unos niveles de acceso a los componentes de la clase para la protección de los mismos.

El acceso a los componentes de una clase se realiza con distintos niveles, con la finalidad de proteger la información contenida en los objetos. Se pueden considerar tres niveles de acceso:

- Privado: Es el nivel de acceso por defecto a los componentes de una clase. Con el nivel de acceso privado los componentes se ocultan para todos los objetos de la clase, siendo sólo accesibles a través de los procedimientos de la clase.
- Público: Con este nivel de acceso los componentes son accesibles directamente por cualquier objeto perteneciente a la clase.
- Protegido: Los componentes son accesibles a través de los procedimientos de la clase, pero tienen características especiales que veremos en el apartado de herencia.

Ejemplo en notación pseudocodificada

clase Empleado (
privado:
num_emp Numérico Entero
nombre Cadena Caracteres (40)
sueldo Numérico Real
público:
num_dpto Numérico Entero
Introducir_Datos Emp( )
INICIO
Leer num_emp
Leer nombre
Leer sueldo
FIN
Escribir_Datos_Emp( )
INICIO
Escribir num_emp, nombre, sueldo
FIN
)

Definición de objetos

Empleado emp1, emp2. Se definen dos objetos de la clase Empleado.

Acceso a los componentes

No se puede acceder directamente desde el programa a los componentes privados. Las siguientes sentencias son incorrectas:

emp1.nombre=”Juan”
emp2.num_emp=20

Tienen que acceder a los componentes privados a través de los métodos.

emp1.Introducir_Datos_Emp( )

Dentro de un programa, los datos pueden ser:

- Globales, que son accesibles por todos los objetos.
- Componentes de una clase, que son accesibles por los objetos de esta clase según su nivel de acceso.
- Locales en un procedimiento, que son accesibles únicamente dentro del procedimiento.

Procedimientos de una clase

Son los métodos definidos para una clase y que pueden ser llamados por los objetos para realizar operaciones con sus datos. Se pueden establecer diversos tipos de procedimientos:

- Procedimientos internos y externos

Se consideran procedimientos internos aquellos que están definidos y desarrollados dentro de la clase y procedimientos externos aquéllos que están declarados en la clase como prototipo y son definidos y desarrollados fuera de la clase.

La definición fuera de la clase obliga a que el nombre del procedimiento vaya precedido por el nombre de la clase donde está declarado acompañado de un símbolo de pertenencia a la clase: A::Cargar_Datos( ).

La ventaja de definir un procedimiento interno es que se ejecuta más rápidamente, pero si existen muchos procedimientos y son de gran tamaño la declaración de la clase se hace más larga y confusa. Los procedimientos externos son llamados cada vez que un objeto los necesita, por lo que son más lentos en la ejecución que un procedimiento interno. Si se quiere que un procedimiento externo funcione como uno interno, se le debe anteponer una palabra clave tal como interno y en ese caso, en vez de ser llamado, lo que hace el compilador es sustituir el código en el programa antes de la ejecución, por lo que el programa ocupará más espacio en memoria.

- Procedimientos amigos

Cuando en una clase los componentes son privados solamente son accesibles por los procedimientos definidos en dicha clase. Si se quiere que una clase pueda tener acceso a los componentes de otra clase, se debe declarar un procedimiento como amigo dentro de cada clase y después definir y desarrollar el procedimiento como externo a dichas clases, sin identificador de la clase a la que pertenece.

Ejemplo:

clase circulo (
privado:
diametro Numerico Real
publico:
Carga_Diam(x)
... ...
**Declaración procedimiento amigo
amigo Igual_Valor(c, r)

clase rectangulo (
privado:
base,altura Num Real
publico: publico:
Carga_Lados(x,y)
... ...
**Declaración proc amigo
amigo Igual_Valor(c,r)

Definición procedimiento amigo

Igual_Valor(c, r)
INICIO
....
FIN

Uso en el programa

circulo c
rectangulo r
c.Carga_Diam(20)
r.Carga_Lados(20,5)
compara=Igual_Valor(c,r)
Si compara=1
Escribir “Diámetro y base iguales”
Si no
Escribir “Diámetro y base distintos”
FinSi

- Métodos constructores y destructores

En la programación orientada a objetos se pueden tener unos procedimientos constructores que asignen unos valores iniciales a los datos de un objeto en el momento de su creación. En el momento de la desaparición del objeto se puede tener un procedimiento destructor que realice una determinada tarea (escribir un mensaje, eliminar memoria reservada, ...) NOTA: En el lenguaje de programación Java, no hace falta utilizar destructores, Java hace el trabajo de limpieza por el usuario.

Los procedimientos constructores se identifican por llevar el mismo nombre de la clase donde están definidos y los procedimientos destructores llevan también el mismo nombre de la clase a la que pertenecen pero precedido por un determinado símbolo. (Por ejemplo, en C++ con el símbolo ~).

Los procedimientos constructores pueden llevar parámetros formales, de tal forma que al crear un objeto se le puedan pasar unos parámetros actuales. Estos parámetros formales se pueden definir por defecto, de tal forma que si no se especifican los valores en los parámetros actuales, los datos toman esos valores por defecto.

- Métodos observadores

Son aquellos métodos que se encargan de devolver un determinado atributo del objeto correspondiente, es decir, “observan” una característica de un objeto.
- Métodos modificadores

Se encargan de modificar un determinado atributo de un objeto. Se suelen utilizar para actualizar características de un objeto, como podría ser por ejemplo, actualizar el saldo actual de una determinada cuenta bancaria.

Mensajes a los objetos

En la programación orientada a objetos los programas emplean objetos que reciben mensajes dentro del programa donde están definidos. Se puede decir que el envío de un mensaje a un objeto consiste en realizar una llamada a un procedimiento que el objeto puede realizar de acuerdo con los procedimientos definidos en la clase a la que pertenece. Los mensajes pueden producir cambios en los datos producidos por un evento que modifica el estado del objeto o pueden realizar cálculos con los datos pertenecientes a un objeto.

Formato para los mensajes en el programa

a) nom-objeto.procedimientos(parámetros)
b) procedimiento-amigo(nom-objeto1, nom-objeto2...)
c) nom-objeto1.procedimiento(nom-objeto2)

Relaciones entre objetos

Durante la ejecución de un programa, los diversos objetos que lo componen han de interactuar entre sí para lograr una serie de objetivos comunes.

Existen varios tipos de relaciones que pueden unir a los diferentes objetos, pero entre ellas destacan las relaciones de: asociación, todo/parte, y generalización/especialización.

a.) Relaciones de Asociación

Serían relaciones generales, en las que un objeto realiza llamadas a los servicios (métodos) de otro, interactuando de esta forma con él.

Representan las relaciones con menos riqueza semántica.

Ejemplo: profesor.imparte(Alumno)

b.) Relaciones de Todo/Parte

Muchas veces una determinada entidad existe como conjunción de otras entidades, como un conglomerado de ellas. La orientación al objeto recoge este tipo de relaciones como dos conceptos; la agregación y la composición.

En este tipo de relaciones un objeto componente se integra en un objeto compuesto. La diferencia entre agregación y composición es que mientras que la composición se entiende que dura durante toda la vida del objeto componedor, en la agregación no tiene por qué ser así.

Esto se puede implementar como un objeto (objeto compuesto) que cuenta entre sus atributos con otro objeto distinto (objeto componente).

Ejemplo Agregación:

JavaPasoAPaso0301.JPG

Ejemplo Composición

JavaPasoAPaso0302.JPG

c.) Relaciones de Generalización/Especialización

Este tipo de relaciones es característico de la programación orientada a objetos.

Lo veremos más adelante como herencia.

En realidad, la generalización y la especialización son diferentes perspectivas del mismo concepto, la generalización es una perspectiva ascendente (bottom-up), mientras que la especialización es una perspectiva descendente (top-down).

Ejemplo Herencia:

JavaPasoAPaso0303.JPG

6. Abstracción

Mediante la abstracción la mente humana modeliza la realidad en forma de objetos. Para ello busca parecidos entre la realidad y la posible implementación de objetos del programa que simulen el funcionamiento de los objetos reales.

Los seres humanos no pensamos en las cosas como un conjunto de cosas menores; por ejemplo, no vemos un cuerpo humano como un conjunto de células. Los humanos entendemos la realidad como objetos con comportamientos bien definidos. No necesitamos conocer los detalles de porqué ni cómo funcionan las cosas; simplemente solicitamos determinadas acciones en espera de una respuesta; cuando una persona desea desplazarse, su cuerpo le responde comenzando a caminar.

Pero la abstracción humana se gestiona de una manera jerárquica, dividiendo sucesivamente sistemas complejos en conjuntos de subsistemas, para así entender más fácilmente la realidad. Esta es la forma de pensar que la orientación a objetos intenta cubrir.

7. Encapsulación

Hemos mencionado que cada objeto es un conjunto de propiedades y métodos, es decir, datos y programas relacionados entre sí como si estuvieran encerrados en una cápsula. Son inaccesibles e impiden conocer cómo está distribuida la información dentro de ellos.

Esto implica que las peticiones de información a un objeto deben hacerse mediante mensajes dirigidos a él. Un mensaje es una simple llamada a un método del objeto con el que se quiere comunicar.

El hecho de ser una cápsula, algo cerrado e inaccesible, favorecerá la depuración de aplicaciones y la reutilización del código en caso de migrarlo a otros entornos.

Hagamos una comparación con lo que sería la vida real. Cuando montamos en un coche nos limitamos a dar a la llave de contacto y el motor arranca. Es muy simple, pero esa simpleza nos la brinda la encapsulación. La realidad es que ocurren muchas cosas: contacto eléctrico, funcionamiento del motor de arranque, apertura del paso de combustible, etc. Pero, ¿necesitamos realmente saber lo que ocurre para hacer uso de él? No, nos basta con saber que para arrancarlo necesitamos introducir la llave en el contacto y girarla.

La encapsulación permite la creación de librerías de clases de uso general, que facilitan la incorporación a los programas de objetos ya definidos proporcionando una mayor rapidez y fiabilidad en el desarrollo de los mismos. Igualmente, se pueden modificar las estructuras de datos y los procedimientos de un objeto sin que afecte al funcionamiento de los demás objetos incluidos en el programa.

El encapsulamiento provee dos principales beneficios a los desarrolladores de software:

- Modularidad, el código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta.
- Ocultamiento de la información, es decir, un objeto tiene una “interfaz pública” que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos privados que pueden sercambiados en cualquier tiempo sin afectar a los otros objetos que dependen
de ellos.

Los objetos proveen el beneficio de la modularidad y ocultamiento de la información. Las clases proveen el beneficio de la reutilización. Los programadores de software utilizan la misma clase, y por lo tanto el mismo código, una y otra vez para crear muchos objetos.

8. Herencia

La herencia es una característica que permite la creación de clases a partir de otras. Esto conlleva tanto la reutilización del código, como la especialización de las clases.

La reutilización del código viene dada porque podemos definir clases nuevas partiendo de otras ya existentes. En este caso se heredan sus propiedades y métodos. La especialización de las clases viene por añadidura ya que, al definir una clase partiendo de otra, lo que estamos es creando una nueva clase más especializada.

Visto lo anterior podemos ya intuir que las clases pueden organizarse jerárquicamente. Esta jerarquía viene determinada por el uso realizado de la herencia.Con esta organización empezamos a tener términos como: clase padre, clase hija, superclase (o clase raíz) y clase final.

- Clase padre o superclase: se dice que una clase es padre de otra cuando sirve como punto de partida para crear a esta última.
- Clase hija o subclase: es aquella clase que hereda de otra, y es hija con respecto a su clase padre o superclase.
- Clase final: toda aquella que no es clase padre de otras.

La herencia puede ser de dos tipos: simple y compuesta. La diferencia entre ambas es que en el caso de herencia compuesta se permite heredar de más de una clase. En otras palabras, se trata de que una clase hija pueda tener más de una clase padre.

En la práctica son pocos los lenguajes que permiten herencia múltiple dada la complejidad que supone soportarla. En el caso de Java no está permitida. Java sólo permite herencia simple pero dispone de un mecanismo para paliar esta deficiencia, aunque no siempre es suficiente. Estamos hablando de las interfaces. El lenguaje Java nos permite heredar de una única clase e implementar varias interfaces.

JavaPasoAPaso0304.JPG

Ejemplo herencia múltiple:

JavaPasoAPaso0305.JPG

9. Polimorfismo

Consiste en la posibilidad de tener métodos con el mismo nombre en distintas clases. Al hablar de métodos en distintas clases nos estamos refiriendo a métodos distintos y por tanto con comportamientos distintos a pesar de que tengan el mismo nombre.

El polimorfismo permite poder enviar un mismo mensaje (recordemos que un mensaje es una invocación a un método) a objetos de clases diferentes. Estos objetos recibirán el mismo mensaje pero responderán a él de formas diferentes. Por ejemplo, un mensaje “+” para un objeto entero significaría una suma, mientras que para un objeto string (cadena de caracteres) significaría la concatenación.

JavaPasoAPaso0306.JPG

Aunque el método dibujar tiene el mismo nombre en todas las clases, cada uno de ellos tendrá una funcionalidad distinta.

El polimorfismo puede ser realizado de las siguientes formas:

- Sobrecarga de procedimientos

Con un mismo nombre de procedimiento se pueden utilizar distintas operaciones. Los procedimientos pueden pertenecer a una sola clase o ser de distintas clases.

Sobrecarga de procedimientos pertenecientes a una clase

Se utiliza un mismo nombre de procedimiento para varios procedimientos definidos en la clase. El compilador conoce el procedimiento que debe utilizar en función de los tipos de datos de los parámetros que emplean los procedimientos sobrecargados. Los procedimientos constructores y los procedimientos amigos se pueden sobrecargar mientras que los procedimientos destructores no se pueden
sobrecargar.

Ejemplo:

clase recorrido (
privado:
distancia Numérico Real
público:
Carga_Dist(x) // Km
Carga_Dist(x, y) //Velocidad y tiempo

Sobrecarga de procedimientos pertenecientes a clases distintas

Se utiliza un mismo nombre de procedimiento dentro de cada clase distinta. El procedimiento que se debe ejecutar será llamado por los objetos y por tanto se efectuará el que está definido en la clase a la que pertenece. En el caso de que las operaciones que vayan a realizar los procedimientos, sean las mismas, se puede definir un procedimiento amigo.

Ejemplo:
xlase coord_2d (
privado:
x,y Numérico Real
público:
Sumar_Coord(c)
)

xlase coord_3d (
privado:
x,y,z Numérico Real
público:
Sumar_Coord(c)
)

<< Volver al tema anterior  || >> Ir al tema siguiente

 

Referencias:

 

http://www.jmordax.com/

 


Autor: Antonio Lopez Atienza


Tags:
Posted in Java | No Comments »

Leave a Comment

 

RSS
MCC D5E