Modulo 1 Fundamentos Programacion Orientada A Objetos

Programación orientada a objetos

Ingenieria de software virtual
1
Tabla de Contenido
1. Introducción ............................................................................................................................. 3
2. Ideograma ................................................................................................................................. 5
3. Tópicos Esenciales ................................................................................................................... 6
3.1. Modularidad ...................................................................................................................... 6
3.2. Abstracción ....................................................................................................................... 7
3.3. Encapsulamiento ............................................................................................................... 8
3.4. Polimorfismo .................................................................................................................... 9
3.5. Herencia .......................................................................................................................... 12
Ejemplo ...................................................................................................................................... 15
Glosario ......................................................................................................................................... 39
Bibliografía .................................................................................................................................... 40
2
Introducción
La programación de computadores ha seguido diversas etapas, pasando por la programación

funcional, la programación estructurada y arribando a la programación orientada por objetos. En la
mayoría de los casos, su evolución ha significado mejoras significativas en cuanto a la
organización, codificación y uso de estructuras de datos y algoritmos. El enfoque de programación
orientada por objetos no deja de significar no solo un avance en la programación de computadores
sino un nuevo enfoque a la solución de problemas.
En realidad, la programación orientada por objetos significa una nueva forma de ver la realidad y
por ende un nuevo enfoque en cuanto a su abstracción y la solución de problemas que a ella
concierne. Los enfoques y metodologías relacionados con el enfoque estructurado concebían la
realidad como una dualidad en la cual se distinguían por un lado los procesos y por otro lado los
datos. En ese sentido el diseño de nuevos programas y sistemas de información se enfocaba
claramente a encontrar primero a partir del análisis de un entorno un diseño de los datos que
respondiera a los elementos que mejor representaran una realidad y una vez identificados los datos
el trabajo restante consistiría en encontrar cuales serían las posibles funciones (funcionalidades)
que se permitieran transformar los datos identificados con miras a describir las principales
operaciones de un negocio.
En términos de lenguajes de programación el problema consistiría en un enfoque estructurado para

encontrar una serie de funciones que harían el tratamiento o transformación de unas estructuras de
datos simples o complejas con el objetivo de llegar a un resultado específico en la solución de un
problema específico. Con la llegada de una nueva propuesta en términos de enfoque o
aproximación, la programación orientada por objetos, se intenta considerar la realidad como un
todo y hacer una representación en términos de clases y de la relación existente entre ellas. La
promesa del nuevo enfoque de orientación por objetos será el de resolver problemas de
independencia de datos y funciones, aumentar la portabilidad de las aplicaciones y de alguna forma
promover la estandarización y la reutilización de código.
3
Con todo lo anterior en mente, el estudioso del presente contenido, tendrá la oportunidad de
aproximarse a la programación orientada por objetos y descubrir en este primer módulo los
conceptos y principios básicos de programación orientada por objetos y al mismo tiempo
aproximarse a java como lenguaje OO con algunos ejemplos y ejercicio.
4
1. Ideograma
Modularidad
Abstracción
Encapsulamiento
Tópicos Fundamentales Polimorfismo
Herencia
Ejercicios
5
2. Tópicos Esenciales
2.1.Modularidad
El paradigma de la programación orientada por objetos comprende diversos principios básicos. El

primero de ellos es el principio de modularidad. Su objetivo principal se orienta a controlar la
complejidad de sistemas de gran escala a través del uso de la técnica divide y vencerás. El principio
se puede enunciar de la siguiente manera; “Un sistema complejo debe ser descompuesto en un
conjunto de módulos altamente cohesionados, pero débilmente acoplados” (Jia, 2003).
La descomposición de sistemas en módulos o piezas pequeñas de software es una disciplina
compleja que muchas veces pasa a ser más un arte que la aplicación de principios científicos. La
justificación de esta última afirmación tiene que ver con el hecho que la mayoría de entidades de
un sistema de software están intrínsecamente interconectadas, pero a la vez deben evitar “enredarse
o mezclarse” unas con otras.
Los dos criterios básicos para la descomposición de los sistemas de software son:
 Cohesión: La cual se refiere a la relación funcional entre las entidades dentro de un módulo.
 Acoplamiento: El cual se refiere a la interdependencia entre diferentes módulos
Un sistema extremadamente complejo puede ser despiezado y organizado usando una

descomposición modular. Esta propende por descomponer la totalidad del sistema en módulos que
cumplan lo siguiente:
Cada módulo debe ser relativamente simple y pequeño (es decir, altamente cohesivo) y la
interacción entre los módulos debe ser relativamente simple (es decir, débilmente acoplado),
asegurando que cada módulo se comportara bien y que, si todos los sistemas se comportan bien, el
sistema como una totalidad también funcionara adecuadamente.
Normalmente, la descomposición modular es de tipo jerárquico, es decir cada módulo puede

contener otros módulos. El concepto de modularidad ha avanzado a lo largo del tiempo, pasando
de su implementación en el enfoque estructurado utilizando funciones y rutinas, al uso de clases y
paquetes en la filosofía orientada por objetos.
6
2.2. Abstracción
El principio de abstracción consiste en separar y distinguir las características esenciales de la

realidad. El resultado esperado de la aplicación de este principio será obtener una aproximación
más sencilla, pero al mismo tiempo lo suficientemente precisa sobre la entidad descrita. El principio
de abstracción aplicado a la ingeniería de software puede ser expresado de la siguiente forma:
Los comportamientos o funcionalidades de un módulo deberán ser caracterizados usando una

descripción precisa y sucinta conocida como la interfaz del módulo. En otras palabras, la interfaz
captura la esencia del comportamiento del módulo. La interfaz es una abstracción del módulo.
En la construcción de un sistema de información o simplemente de una aplicación la

descomposición en módulos conjugada con la abstracción lleva a mirar cada módulo como un
proveedor de servicios y a los restantes módulos como clientes del primero. Podemos considerar
la interfaz del módulo como un contrato de servicio entre el proveedor y los clientes. Dicho contrato
de servicio necesita exclusivamente describir cuales servicios pueden ser provistos y no cómo serán
provistos. Por consiguiente, si bien el conjunto de servicios puede llegar a ser extremadamente
complejo, el contrato de servicios deberá ser lo más simple posible. Con un contrato de servicios
simple y con la confianza que el proveedor del servicio cumplirá el contrato, los clientes solamente
necesitan entender dicho contrato para poder utilizar el conjunto complejo de servicios. La interfaz
de cada contrato les permitirá a los clientes usar los servicios sin preocuparse con la complejidad
de todo el conjunto de servicios. En otras palabras, la complejidad de los servicios esta oculta en
este.
Miremos un ejemplo concreto. Consideremos un teléfono. El mecanismo para proveer el servicio

telefónico es complejo. Involucra el enrutamiento y la conexión de las llamadas, la conversión de
la voz en señales eléctricas y lo contrario, la transmisión de señales en forma digital o análoga y
posiblemente el encriptamiento y desencriptamiento de las señales por razones de seguridad. Sin
embargo, los usuarios de un teléfono no necesitan entender los intrincados procesos y mecanismos
de un teléfono. Los usuarios necesitan entender el manual que viene con el aparato telefónico, que
incluye las instrucciones para marcar, hablar y colgar. El manual de usuario, en este caso, es la
7
interfaz contractual del servicio telefónico y sirve como abstracción del servicio telefónico desde
la perspectiva del usuario.
2.3.Encapsulamiento
Otro principio muy relacionado y complementario es el principio de encapsulamiento, que estipula

que los clientes no necesitan saber más que el contrato de servicio cuando están utilizando el
mismo.
El principio se puede establecer de la siguiente manera:
La implementación de un módulo deberá estar separada de su interfaz contractual y oculta de los
clientes del mismo.
La razón de ser del encapsulamiento es doble: En primer lugar, se aplica el encapsulamiento para
permitir a un objeto de asegurase su propia integridad, suconstrucción y su destrucción. Por tanto,
se obliga a que toda modificación de los atributos de un objeto pase por un mismo sitio, por un
mismo método. El objetivo es permitir al objeto aplicar ese principio de manera estricta, sobre todo
si el objeto es riguroso y utiliza los mecanismos de control de acceso.
El principio de encapsulamiento es conocido también como ocultamiento de información. El

encapsulamiento se utiliza para reducir el acoplamiento de los módulos. Entre menos conozcan los
clientes acerca de la implementación del módulo, menor será el grado de acoplamiento entre el
modulo y sus clientes. Un beneficio importante del encapsulamiento es que, si los clientes no
conocen nada más allá de la interfaz contractual, la implementación podrá modificada sin afectar
a los mismos.
El servicio telefónico es un buen ejemplo de una aplicación en la cual la interfaz contractual y su

implementación están separadas. Antes, las señales eran transmitidas de forma análoga. Al pasar
el tiempo y con el avance de la física de ondas aplicadas al servicio de la sociedad, esta manera ha
sido graduablemente transformada hasta llegar ahora a ser transmitida en forma digital con
encriptamiento. Aunque la implementación del servicio telefónico ha cambiado, la interfaz
8
contractual es básicamente igual. Lo único necesario para que un usuario pueda comunicarse
telefónicamente es saber para un aparato telefónico especifico descolgar, marcar y colgar, no
importa qué tipo de mecanismo de telefonía está utilizando: análoga, digital, 3G, 4G etc. Sin
cambiar la interfaz contractual, los usuarios telefónicos pueden ahora gozar de una mejor calidad
de sonido y una mayor seguridad en sus comunicaciones.
Si la interfaz contractual está completamente separada de su implementación, la interfaz

contractual puede existir ella misma. Una interfaz contractual sin ninguna implementación asociada
se conoce como interface en la terminología Java. Un módulo puede ser representado por 2
entidades separadas: una interface contractual del módulo y una clase que implementa esta interfaz
contractual.
2.4.Polimorfismo
El polimorfismo consiste en la habilidad o posibilidad de intercambiar módulos dinámicamente sin

afectar a los clientes. Ejemplo de ello es un teléfono capaz de funcionar con tecnología análoga o
tecnología digital. Los servicios de telefonía pueden asumir diversos modos para el procesamiento
y transmisión de señales, pero los clientes, en este caso, representados por los dispositivos de
telefonía (celular) poseen la capacidad de funcionar en diferentes modos.
Esta posibilidad es implementada y puesta en práctica usando una de las características más
importantes de los lenguajes de programación orientada a objetos: enlace dinámico de métodos.
Este puede hacerse en tiempo de ejecución o en tiempo de compilación.
9
Antes de ahondar más en el tema de enlace dinámico es necesario discutir otros aspectos de algunos
términos de orientación a objetos tales como: variable, objeto, clase y tipo.
Una variable es un espacio de memoria que nos permite contener algún dato para representar un
hecho de la realidad. La variable tiene un identificador, un almacenamiento relacionado con la
misma y un tipo que nos dice a qué categoría pertenece la variable: booleana, entera, real, carácter.
En el curso de Lógica de programación se discutió acerca del significado de las mismas y se explicó
con algún grado de detalle su conceptualización.
Un objeto es una representación de algo tangible o intangible del cual queremos mantener
información. Un objeto está compuesto básicamente de una identificación, unas propiedades o
estado y un comportamiento.
El estado determina las condiciones en las que existe un objeto. Es la combinación de los valores
de las propiedades lo que determina en qué estado se encuentra un objeto y es en función de sus
transiciones que podemos determinar los diferentes momentos de la vida del objeto. Por ejemplo,
un vehículo (objeto) puede pasar de un estado detenido, en marcha, acelerando, desacelerando etc.
O también puede estar en reparación, estrellado, arreglado etc. Como lo veremos posteriormente
en términos de orientación a objetos es muy importante conocer cuáles son las posibles transiciones
de un objeto para así obtener el diagrama de transiciones del mismo. En la siguiente figura se ilustra
un diagrama de transiciones para un objeto.
10
Figura 1. Diagrama de transiciones de un objeto
El comportamiento corresponde a las diferentes maneras de interactuar del objeto con su entorno.
Por ejemplo, en el caso del vehículo como responde a las acciones o mensajes dirigidos por otro
objeto, por ejemplo, el conductor. Este objeto puede enviar el mensaje arrancar al objeto vehículo
y la acción a seguir estará determinada por el comportamiento definido en la clase vehículo. Cada
acción definirá un método y el conjunto de los métodos de un objeto dará como resultado el
comportamiento general y especifico del objeto. Lo anterior se ilustra en la figura 2.
11
Figura 2. Diagrama de actividades correspondiente al comportamiento de objetos de una aplicación
2.5.Herencia
El concepto de herencia es uno de los más importantes en la Teoría de la programación orientada

por objetos. Constituye una de las relaciones más importantes en el modelamiento orientado por
objetos. Específicamente, existe diversos tipos de relación tales como:
12
 Extensión entre dos clases. Decimos que la clase C2 extiende la clase C1y por tanto la clase
C2 se denomina subclase de la clase C1 y la clase C1 se denomina a su vez superclase de
C2.
 Extensión entre dos interfaces. Cuando la interfaz I2 extiende la interfaz T1, la interfaz I2
se conoce como subinterfaz de I1 y a su vez la interfaz I1 se conoce como superinterfaz de
I2.
 Implementación entre una clase y una interfaz. Cuando una clase C2 implementa la interfaz
I1, la clase C2 se conoce como la implementación de la interfaz I1 y la interfaz I1 se le da
el nombre de interfaz de la clase C2
Usando el lenguaje de modelado UML podemos apreciar en la figura 1, la representación gráfica

de las relaciones definidas anteriormente.
Figura 3. Relaciones entre clases e Interfaces
Con respecto a la figura 3 es posible hacer las siguientes precisiones esa relación de extensión es
conocida también como especialización, y la relación inversa se conoce como generalización en
términos de la notación UML. La relación de implementación es conocida como realización en la
terminología UML.
Gráficamente como lo podemos apreciar en la figura la relación es representada por una flecha o
vínculo que parte de la subclase/subinterfaz y se dirige hacia la superclase/superinterfaz. La
13
relación de extensión (sea esta especialización o generalización) es representada con una flecha
continua mientras que la relación de implementación es representada usando una flecha punteada.
Conceptualmente los modelos de herencia se traducen en la práctica en relaciones de tipo es-un

(En inglés is-a). En otras palabras, si C2 es una subclase/subinterfaz/implementación de C1,
entonces toda instancia de C2 es una instancia de C1 y todo lo que sea aplicable a C1 también
podrá serlo para las instancias de C2. La noción de extensión entre dos clases se asocia comúnmente
con la noción de reutilizar o compartir la implementación (es decir sus atributos y métodos) de una
superclase por sus subclases. La relación de extensión entre dos interfaces representa la expansión
de un contrato de servicio. La relación de implementación no conlleva reutilización de sus
implementaciones, pero por el contrario si implica implementación de la interfaz contractual por
parte de una clase
Considerando el siguiente ejemplo que representa los diferentes grupos de estudiantes en una
universidad. La figura 4 muestra el diagrama de clases. Es fácil apreciar en esta grafica como la
herencia puede ser interpretada como una relación es-un (is-a). Por ejemplo, la clase posgrado es
una subclase de estudiante. El conjunto de estudiantes, es decir el conjunto de instancias de la clase
estudiante, es un superconjunto (superset) del conjunto de estudiantes graduados, es decir, el
conjunto de esto que todo estudiante de postgrado es un estudiante, y todo lo que se aplique a un
estudiante también se puede aplicar para el estudiante de postgrado. El conjunto de estudiantes es
una superclase de la clase de estudiantes graduados.
Figura 4. Ejemplo de un diagrama de clase
14
Ejemplo
A continuación, revisaremos un ejemplo completo que nos permitirá entender con mayor precisión
los conceptos de orientación a objetos incluida la herencia, revisados en los anteriormente.
El problema de programación propuesto consiste en desarrollar una aplicación sencilla en java,

utilizando el enfoque de programación orientada por objetos, que nos permita implementar un
tablero mágico para dibujar de manera libre con el mouse. Para cumplir con esta misión
estableceremos un plan que nos permita dividir nuestro desarrollo en diferentes pasos o
actividades:
 Definir un bosquejo de nuestro tablero

 Elaborar el diseño general de las clases a usar
 Escribir cada una de las superclases y subclases
 Escribir la clase principal que implementara nuestro diseño
 Hacer la prueba de nuestra aplicación
 Documentar nuestro trabajo
El objetivo de esta primera versión o iteración es entregar una versión de la aplicación que
contenga un número mínimo de funcionalidades. La aplicación consistirá de un frame (cuadro) que
contendrá un canvas (lienzo). Una primera impresión de la aplicación se aprecia en la figura 5.
15
Figura 5. Ejemplo de un diagrama de clase
A continuación, se presenta en la figura 6, el diseño conceptual inicial de la aplicación
Figura 6. Diseño conceptual Inicial aplicación tablero mágico
16
En esta primera iteración, se desarrollan las clases que están sombreadas en la figura 6. Las
restantes son clases e interfaces pertenecientes a la librería de clases de java. Las clases a desarrollar
se ilustran en la figura 7.
Figura 7. Clases a desarrollar en la primera versión del tablero mágico
Una vez sorteados los pasos 1 y 2, es decir el bosquejo y el diseño inicial de clases, procederemos
a la escritura de cada una de ellas: Tablero, TableroCanvas y TableroCanvasListener. Tomando
primero TableroCanvas, este será el primer componente de la interfaz gráfica (GUI) donde
tendremos todas las herramientas graficas a nuestra disposición. El Listado con el código fuente
completo lo pueden revisar en la figura No. 8. Esta clase es un bello ejemplo del concepto de
herencia. Ella misma extiende a la clase javax.swing.jPanel. Esta clase es una de las varias que
conforman el cuadro referencial y la librería Swing. Swing fue desarrollado como una respuesta a
las innumerables obstáculos y restricciones encontrado por los desarrolladores al utilizar el cuadro
grafico referencial de java (Abstract Window Toolkit).
Como una clase java que representa un conjunto de objetos con ciertas características y métodos
comunes, inicialmente la clase TableroCanvas contendrá los siguientes campos (atributos o
miembros en la terminología de POO):
17
 mouseButtonDown: para facilitar la detección de cuando el mouse está siendo presionado.

Nótese que el campo es tipo booleano, es decir puede asumir solamente los valores true o
false.
 x,y : estos dos campos contendrán las coordenadas x e y que nos dará la posición del cursor
en el canvas o cuadro . Estos dos campos son de tipo entero.
 listener: Contendrá una referencia al objeto de la clase Listener del Canvas.
Figura 8. Listado Fuente clase Tablero Canvas - Aplicación Tablero Mágic
Por su parte la clase TableroCanvasListener (figura No. 9) manejara los eventos del mouse que
ocurren en el canvas. El comportamiento deseado del tablero contendrá inicialmente las
siguientes acciones:
 El dibujo de un punto (pixel) se inicia cuando el botón derecho del mouse es presionado.
 El dibujo continua mientras el mouse es presionado y movido al interior del canvas.
 El dibujo del punto finaliza cuando se libera el botón derecho del mouse
Existen al interior de la clase TableroCanvasListener, dos interfaces que permiten describir y

manejar el comportamiento del mouse, ellas son:
18
 Java.awt.event.MouseListener: para administrar los eventos relacionados con las acciones

en los botones del mouse, tal como presionar o liberar.
 Java.awt.event.MouseMotionListener: para eventos relacionados con el movimiento del
mouse, tal como mover o arrastrar.
La clase TableroCanvasListener debe manejar las acciones de presionar y liberar el botón del
mouse y las acciones de arrastrar. Así que, debe implementar 2 interfaces de tipo listener:
MouseListener y MouseMotionListener. Los métodos relevantes para esta primera versión de
nuestro tablero mágico son:
 mousePressed() Notifica cuando se presiona el botón del mouse

 mouseReleased() Notifica cuando se libera el botón del mouse
 mousedragged() Notifica cuando se ejecuta la acción de arrastrar el botón
Aunque existen otros métodos declarados en las interfaces MouseListener y MouseMotionLIstener

por el momento no serán utilizadas y por tanto su implementación no contendrá ninguna
instrucción.
El método mousePressed manejara el comienzo de cada punto o línea. Este método fija en verdadero
el valor de la variable mouseButtonDown y almacena la posición actual del mouse. Dicha posición
se obtiene invocando el método e.getPoint(). La posición es relativa a la esquina superior
izquierda del canvas.
Mientras el mouse es arrastrado, se crean una serie de eventos de tipo mouse drag (arrastrar el
mouse) en tiempo de ejecución. Cada evento indica la posición actual del mouse. El evento
mouseDragged maneja la continuación del punto o la línea. Dibuja una línea desde la posición actual
y actualiza la posición corriente o actual del mouse en el canvas del tablero.
El método MouseReleased maneja el final del dibujo de una línea, fijando el valor de la variable
mouseButtonDown del canvas a falso. Por otra parte, el constructor de la clase TableroCanvas
crea una instancia de la clase TableroCanvasListener y registra o inscribe los listeners
MouseListener y MouseMotionListener.
19
Figura 9. Listado del código fuente de la clase TableroCanvasListener
Finalmente completando esta primera iteración encontramos en la figura 10 el listado del código
fuente de la clase Tablero, la cual será aquella desde la cual se invocaran y manejaran las otras
clases participantes en la aplicación. Como lo notaran, esta clase posee un método main que
convierte esta clase en una clase ejecutable, es decir será la primera clase invocada una vez inicie
la aplicación. Desde allí, se inicializa el canvas y se definen algunas de las propiedades de cada
uno de los contenedores de los objetos de la interfaz tales como: el color de fondo, la forma como
aparecerán los objetos, el título de la ventana del canvas y además se declaran y definen cada uno
de los listeners que utilizara la aplicación para controlar la interfaz.
20
Figura 10. Listado del código fuente clase Tablero – Aplicación Tablero Mágico
Ahora se continua con una segunda iteración en el desarrollo de nuestro tablero mágico. Los
objetivos fijados para esta segunda iteración serán:
 Guardar los dibujos internamente, de tal forma que puedan volverse a dibujar.
 Guardar los dibujos en archivos y cargar los dibujos a partir de archivos.
 Construir una barra de menús.
 Usar menú de diálogos para facilitar a la interacción con la interfaz.
 Crear una paleta de colores para seleccionar los mismos.
La figura 11 ilustra el siguiente objetivo en términos de interface mostrando la interfaz que vamos
a implementar en este segundo ciclo de desarrollo.
21
Figura 11.Imagen de la Interfaz para la segunda iteración de la aplicación del Tablero mágico
Uno de los inconvenientes con la primera versión de nuestro tablero mágico tenía que ver con el
hecho que no podíamos minimizar nuestra aplicación porque perdíamos lo que habíamos dibujado
pues todo lo dibujábamos directamente en el canvas del objeto TableroCanvasListener y no lo
almacenábamos en ninguna otra parte internamente.
Al igual que en la primera iteración debemos, adicional al bosquejo de nuestra interfaz añadir los
siguientes pasos:
 Elaborar el diseño general de las clases a usar

 Escribir cada una de las superclases y subclases
 Modificar la clase principal que implementa nuestro diseño
 Hacer la prueba de nuestra aplicación
 Documentar nuestro trabajo
En esta segunda iteración, con el propósito de retener los dibujos y poder redibujar el canvas, los
dibujos serán almacenados internamente y repintados cuando sea necesario.
Para esto, se plantea utiliza la siguiente estructura:
22
Figura 12.Diseño de clases – segunda iteración aplicación tablero mágico
La clase Trazo representa un trazo simple en un dibujo. Puesto que necesitamos guardar los dibujos
en archivos, hemos hecho la clase trazo serializable, es decir permitirle que posea un mecanismo
para salvar y cargar los dibujos. Los campos de la clase Trazo son:
Campos Descripción
Points Lista de puntos que conforman el trazo
Color Color del trazo
Y los siguientes son los métodos de dicha clase:
Métodos Descripción
setColor() Fija el color del trazo
getColor() Selecciona el color del trazo
addPoint Adiciona un punto al trazo
getPoints() Retorna la lista de puntos
La figura 13 ilustra el listado para la clase Trazo
23
Figura 13.Listado del código fuente de la clase Trazo
Por otra parte, la clase TableroCanvas ha sido rediseñada con el propósito de guardar el dibujo
como una lista de trazos y repintarlas cuando sea necesario. Adicional a los campos ya existentes,
se han agregado los siguientes campos:
Campos Descripción
Trazos Lista de los trazos
curTrazo Trazo actual o corriente, mientras es dibujado
curColor Color actual del trazo
A su vez, los métodos de la clase TableroCanvas se resumen a continuación:
24
setCurColor() Fija el color corriente
getCurColor(0 Recupera el color corriente
startTrazo() Método invocado por el listener para comenzar un nuevo trazo. Un nuevo trazo es
creado
addPointToTrazo() Invocado por el listener para adicionar (append) un punto al trazo corriente. Se
adiciona un nuevo punto al trazo corriente
finTrazo() Invocado por el listener para terminar un nuevo trazo. El trazo corriente se
adiciona a la lista de trazos.
paint() Invocado por el listener en tiempo de ejecución cuando quiera que el canvas deba
volverse a pintar. El dibujo es repintado en el canvas recuperando los trazos
guardados previamente
newFile() Crea un nuevo dibujo y un nuevo archivo
saveFile() Salva el dibujo actual al archivo usando una serializacion del objeto
openFile() Carga el dibujo a partir de un archivo desserializando el objeto almacenado
La figura 14 incluye el listado completo de la clase TableroCanvas.
25
26
27
Figura 14. Listado fuente de la clase TableroCanvas – aplicación tablero mágico – 2da iteración
Ahora, se revisara la redefinición de la clase TableroCanvasListener. Esta es muy similar a la

versión de la primera iteración. Sin embargo, en esta ocasión hemos adicionado el dibujo de los
puntos del trazo en el canvas, los cuales también deberán ser almacenados en la lista trazos. Los
métodos startTrazo(), addPoitnToTrazo(), o finTrazo() del canvas se invocan por los métodos
mousePressed(), mouseReleased() o mouseDragged() del listener, respectivamente.
A continuación, la figura 15 incluye el listado fuente completo de la clase TableroCanvasListener

redefinida para esta segunda iteración:
28
Figura 15. Listado fuente de la clase TableroCanvasListener – aplicación tablero mágico – 2da iteración
29
Por su parte la clase Tablero es la clase principal o punto de entrada de toda la aplicación. Esta
segunda versión contiene una barra de menú y un conjunto de clases anidadas, las cuales son los
listeners para los ítems incluidos en la barra de menú. Los siguientes son los métodos de la clase
tablero:
createMenuBar() Crea la barra de menú
newFile() Comienza el dibujo e instancia un nuevo archivo
openFile() Carga el dibujo a partir del archivo especificado
saveFile() Salva el dibujo corriente en el archivo corriente
saveFileAs() Salva el dibujo corriente al archivo especificado
Las siguientes son las clases anidadas en la clase Tablero.
Clase anidadas Descripción

NewFileListener Acción para el ítem “New”
OpenFileListener Acción para el ítem “Open”
SaveFileListener Acción para el ítem “Save”
SaveAsFileListener Acción para el ítem “Save As”
ExitListener Acción para el ítem “Exit”
ColorListener Acción para el ítem “Color”
AboutListener Acción para el ítem “About”
En las figuras 16 y 17 se ilustra el código fuente para la clase Tablero y las clases anidadas
utilizadas en esta segunda iteración:
30
31
32
Figura 16. Listado fuente de la clase tablero – Aplicación Tablero mágico 2da. Iteración
En la figura 17, se incluye el listado fuente de las clases anidadas
33
Figura 17. Listado fuente de las clases anidadas – aplicación Tablero mágico 2da. Iteración
Como se puede apreciar, en el constructor de la clase Tablero, se crea la barra de menú y se coloca
sobre el canvas. La barra de menú es creada con el método createMenuBar(). Es necesario tener en
cuenta que cada ítem se asocia con una acción de listener para manejar la activación del código
según sea la escogencia o selección del usuario.
La acción más sencilla es aquella del método AboutListsener, el cual maneja la acción del ítem
About en el menú Help. Cuando un usuario selecciona esta opción se muestra un dialogo donde se
despliega un panel tal como se muestra en la figura 18. La clase JOptionPane provee varios métodos
estáticos para desplegar los diálogos o cajas de diálogos más comunes con una invocación de un
simple método.
34
Figura 18. Ilustración del resultado de accionar el ítem About de la opción de Menu Help
La clase NewFileListener maneja la acción de la opción de menú New en el menú File. Por su parte
la clase OpenFileListener maneja la opción Open del menú File. Esta, por su parte, utiliza la clase
JFileChooser para habilitar el despliegue de un dialogo donde el usuario puede seleccionar un
archivo, tal como se muestra en la figura 19. Después de la selección del archivo, la acción se
delega al método openFile() usando el nombre de archivo, utilizando la clase definida
SaveAsFileListener.
35
Figura 19. Ilustración del resultado de accionar el ítem Open de la opción de Menú File
Por su parte, la clase ExitListener maneja la acción Exit del ítem del menú File. Esta despliega una
caja de dialogo simple usando la clase javax.swing.JOptionPane tal como se muestra en la figura
20, para confirmar si el usuario quiere o no guardar su dibujo.
36
Figura 20. Ilustración del resultado de accionar el ítem Exit de la opción de Menu File
Los métodos utilizados para manejar los archivos mantienen el nombre de archivo corriente y
delegan la mayor parte del trabajo al método correspondiente en la clase TableroCanvas.
La clase ColorListener maneja la acción del ítem Color en la opción de Menú. Este despliega un
dialogo mostrando las diferentes opciones de color tal como se muestra en la figura 21
Figura 21. Ilustración del resultado de accionar el ítem Color del menú Option
37
El comportamiento del dialogo está definido en la clase ColorDialog cuyo listado fuente se puede
consultar en el paquete incluido como recurso del módulo, pero el cual debido a su extensión
consideramos no pertinente incluirlo como parte de este contenido.
Con esta explicación más o menos detallada del desarrollo de la aplicación de Tablero Mágico el
estudioso tiene ya una base práctica que le permitirá a lo largo del curso abstraer y utilizar los
elementos de la programación orientada por objetos. En los siguientes dos módulos ilustraremos
otros conceptos fundamentales de la programación orientada a objetos reutilizando parte del código
ya hecho y ampliando el desarrollo de la aplicación base de nuestro tablero mágico.
38
Glosario
Clase: Una clase es una colección de objetos que comparten características comunes y
comportamientos parecidos, de tal forma que podemos encontrar una abstracción que los defina y
nos permita automatizar su definición y comportamiento
Encapsulamiento: es un principio de orientación a objetos que permite ocultar las propiedades

inherentes a un objeto y solamente hacer públicas aquellas realmente importantes para su acceso
público
Herencia: Constituye una de las relaciones más importantes en el modelamiento orientado por
objetos. Existen relaciones tales como la extensión e implementación que permiten describir
relaciones de herencia.
Instancia: Es un subconjunto de valores de los diferentes atributos de un objeto que define su

existencia y estado en un instante determinado del tiempo. Cada instancia tiene un espacio de
memoria donde son guardados los valores correspondientes de los atributos del objeto y existe una
referencia que permite saber dónde está contendía dicha información.
Método: Un método es un elemento constitutivo de un objeto por medio del cual describimos un
conjunto de acciones que conforman un comportamiento del objeto, es decir la forma de reaccionar
frente a estímulos o mensajes de otros objetos o de otros métodos al interior del objeto
Objeto: Un objeto es una representación de algo tangible o intangible del cual queremos mantener
información. Un objeto está compuesto básicamente de una identificación, unas propiedades o
estado y un comportamiento.
Polimorfismo: Es la habilidad o posibilidad de intercambiar módulos dinámicamente sin afectar a

los clientes
39
Bibliografía
Eck, J. (2018). Introduction to Programming Using Java. Introduction to Programming Using Java.
Geneva NY: Department of Mathematics and Computer Science - Hobart and William Smith
Colleges.
Xiaoping, J. (2003). Object-Oriented software development using JAVA. U S : Addison Wesley.
Jimenez, L et Al. (2006). Analogías graficas como método de aprendizaje en un curso de

Programación Orientada a Objetos. En revista de Ingeniería Informática, edición 13, Noviembre
del 2006. Universidad Católica del Maule, Talca – Chile.
Poo, D, Kiong, D y Snwaralatha, D. (2008) Object Oriented Programming. USA: Springer 2008.
40

Modulo 1 Fundamentos Programacion Orientada A Objetos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo 1 Fundamentos Programacion Orientada A Objetos

Cargado por

Copyright:

Formatos disponibles

Programación orientada a objetos

Programación orientada a objetos

3. Tópicos Esenciales ................................................................................................................... 6

3.1. Modularidad ...................................................................................................................... 6

3.2. Abstracción ....................................................................................................................... 7

3.3. Encapsulamiento ............................................................................................................... 8

3.4. Polimorfismo .................................................................................................................... 9

3.5. Herencia .......................................................................................................................... 12

La programación de computadores ha seguido diversas etapas, pasando por la programación

En términos de lenguajes de programación el problema consistiría en un enfoque estructurado para

Tópicos Fundamentales Polimorfismo

El paradigma de la programación orientada por objetos comprende diversos principios básicos. El

Un sistema extremadamente complejo puede ser despiezado y organizado usando una

Normalmente, la descomposición modular es de tipo jerárquico, es decir cada módulo puede

El principio de abstracción consiste en separar y distinguir las características esenciales de la

Los comportamientos o funcionalidades de un módulo deberán ser caracterizados usando una

En la construcción de un sistema de información o simplemente de una aplicación la

Miremos un ejemplo concreto. Consideremos un teléfono. El mecanismo para proveer el servicio

Otro principio muy relacionado y complementario es el principio de encapsulamiento, que estipula

El principio de encapsulamiento es conocido también como ocultamiento de información. El

El servicio telefónico es un buen ejemplo de una aplicación en la cual la interfaz contractual y su

Si la interfaz contractual está completamente separada de su implementación, la interfaz

El polimorfismo consiste en la habilidad o posibilidad de intercambiar módulos dinámicamente sin

Figura 1. Diagrama de transiciones de un objeto

Figura 2. Diagrama de actividades correspondiente al comportamiento de objetos de una aplicación

El concepto de herencia es uno de los más importantes en la Teoría de la programación orientada

Usando el lenguaje de modelado UML podemos apreciar en la figura 1, la representación gráfica

Figura 3. Relaciones entre clases e Interfaces

Conceptualmente los modelos de herencia se traducen en la práctica en relaciones de tipo es-un

Figura 4. Ejemplo de un diagrama de clase

El problema de programación propuesto consiste en desarrollar una aplicación sencilla en java,

 Definir un bosquejo de nuestro tablero

Figura 5. Ejemplo de un diagrama de clase

A continuación, se presenta en la figura 6, el diseño conceptual inicial de la aplicación

Figura 6. Diseño conceptual Inicial aplicación tablero mágico

Figura 7. Clases a desarrollar en la primera versión del tablero mágico

 mouseButtonDown: para facilitar la detección de cuando el mouse está siendo presionado.

Figura 8. Listado Fuente clase Tablero Canvas - Aplicación Tablero Mágic

Existen al interior de la clase TableroCanvasListener, dos interfaces que permiten describir y

 Java.awt.event.MouseListener: para administrar los eventos relacionados con las acciones

 mousePressed() Notifica cuando se presiona el botón del mouse

Aunque existen otros métodos declarados en las interfaces MouseListener y MouseMotionLIstener

Figura 9. Listado del código fuente de la clase TableroCanvasListener

 Elaborar el diseño general de las clases a usar

Figura 12.Diseño de clases – segunda iteración aplicación tablero mágico

Y los siguientes son los métodos de dicha clase:

La figura 13 ilustra el listado para la clase Trazo

Figura 13.Listado del código fuente de la clase Trazo

La figura 14 incluye el listado completo de la clase TableroCanvas.

Ahora, se revisara la redefinición de la clase TableroCanvasListener. Esta es muy similar a la

A continuación, la figura 15 incluye el listado fuente completo de la clase TableroCanvasListener

Las siguientes son las clases anidadas en la clase Tablero.

Clase anidadas Descripción

En la figura 17, se incluye el listado fuente de las clases anidadas

Encapsulamiento: es un principio de orientación a objetos que permite ocultar las propiedades

Instancia: Es un subconjunto de valores de los diferentes atributos de un objeto que define su

Polimorfismo: Es la habilidad o posibilidad de intercambiar módulos dinámicamente sin afectar a

Xiaoping, J. (2003). Object-Oriented software development using JAVA. U S : Addison Wesley.

Jimenez, L et Al. (2006). Analogías graficas como método de aprendizaje en un curso de

También podría gustarte