Índice general

Índice de figuras III

Índice de tablas IV

1. Introducción 1

2. Clases y relaciones 3
2.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Interacción entre objetos . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Relaciones entre clases . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Asociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Agregación . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Composición . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.4. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5. Dependencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.6. Realización . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Herencia 15
3.1. Tipos de herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Herencia simple . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Herencia multi-nivel . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. Herencia jerárquica . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4. Herencia múltiple . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Interfaces en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

i
 ÍNDICE GENERAL

3.3. Clases abstractas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4. Encapsulamiento y ocultamiento 24
4.1. Encapsulamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1. Por medio de métodos . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Por medio de clases . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3. Por medio de paquetes . . . . . . . . . . . . . . . . . . . . . 26
4.2. Ocultamiento de información . . . . . . . . . . . . . . . . . . . . . . 27

5. Polimorfismo 30
5.1. Polimorfismo de Inclusión (o Subtipado) . . . . . . . . . . . . . . . 30
5.2. Polimorfismo Paramétrico . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. Polimorfismo de Sobrecarga . . . . . . . . . . . . . . . . . . . . . . 35
5.3.1. Ejemplo: Sobrecarga de constructores . . . . . . . . . . . . . 36
5.3.2. Ejemplo: Sobrecarga de métodos . . . . . . . . . . . . . . . 37

Acrónimos 38

ii
Índice de figuras

2.1. Representación de un objeto. . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Representación de un objeto persona . . . . . . . . . . . . . . . . . 5
2.3. Representación de una clase Automóvil. . . . . . . . . . . . . . . . 6
2.4. Relación de asociación. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Relación de agregación. . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Relación de composición. . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7. Relación de herencia. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Relación de dependencia. . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9. Relación de realización. . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Tipos de herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2. Ambigüedad en la herencia múltiple. . . . . . . . . . . . . . . . . . 18

4.1. Paquetes en un proyecto. . . . . . . . . . . . . . . . . . . . . . . . . 27

iii
Índice de tablas

4.1. Modificadores de ocultamiento de información en Java. . . . . . . . 28

iv
Capı́tulo 1

Introducción

La Programación Orientada a Objetos (POO) ha revolucionado el panorama

de la ingenierı́a de software, ofreciendo un enfoque holı́stico y modular para el
desarrollo de aplicaciones complejas. Esta metodologı́a se basa en el concepto de
.objetos”, que son entidades que combinan datos y comportamientos, representando
ası́ elementos del mundo real o abstracto en el código.
La motivación para adoptar la POO surge de su poder para simplificar el
desarrollo de software y mejorar su calidad. En un mundo cada vez más dependiente
de sistemas complejos e interconectados, la necesidad de un enfoque que ofrezca
soluciones robustas, reutilizables y fáciles de mantener es primordial. La POO
responde a estas necesidades a través de sus caracterı́sticas clave:

• Abstracción: Ayuda a enfocar en lo que un objeto hace, en lugar de cómo lo

hace, permitiendo a los desarrolladores trabajar en un nivel más conceptual
y menos detallado.

• Herencia: Facilita la reutilización de código y la extensión de funcionali-

dades existentes de manera ordenada y lógica, permitiendo que las nuevas
clases deriven propiedades y comportamientos de las clases existentes.

• Encapsulación: Permite esconder la complejidad interna de los objetos, ex-

poniendo solo aquello que es necesario para el resto del sistema. Esto conduce
a una mayor seguridad del código y reduce las interdependencias complejas.

1
 • Ocultamiento de Información: Junto al encapsulamiento, el ocultamiento
de información es fundamental para la seguridad y la robustez del código.
Mediante este principio, los detalles internos del funcionamiento de un objeto
se mantienen ocultos del exterior, exponiendo solo lo que es necesario para
su uso. Esto evita que el estado interno del objeto sea alterado de manera
inapropiada, preservando la integridad y la fiabilidad del programa.

• Polimorfismo: A través de esta caracterı́stica, los objetos de diferentes cla-

ses pueden ser tratados como objetos de una clase común, lo que permite
escribir código más genérico y flexible.

Estas caracterı́sticas hacen que la POO sea especialmente adecuada para ma-
nejar proyectos de software grandes y complejos, facilitando su escalabilidad, man-
tenimiento y colaboración. Empresas y desarrolladores se inclinan hacia la POO
no solo para resolver problemas complejos de manera eficiente, sino también pa-
ra crear un código que sea intuitivo y alineado con la forma en que pensamos y
entendemos el mundo.
El presente documento se organiza de la siguiente forma:

• En este primer Capı́tulo, Capı́tulo 1, se da una pequeña introducción de la

POO mencionando los pilares que hacen esta filosofı́a: Abstracción, Herencia,
Encapsulamiento, Ocultamiento y Polimorfismo.

• El Capı́tulo 2 se definen los conceptos básicos de POO y se describen las

relaciones entre clases.

• El Capı́tulo 3 se entra a detalle al concepto de herencia y las diferentes formas

en las que se puede presentar.

• El Capı́tulo 4 describe el encapsulamiento y el ocultamiento.

• Finalmente el Capı́tulo 5 describe el polimorfismo y sus diferentes tipos.

2
Capı́tulo 2

Clases y relaciones

La programación orientada a objetos (POO) es una ”filosofı́a”, un modelo de

programación, con su teorı́a y su metodologı́a. Un lenguaje orientado a objetos es
un lenguaje de programación que permite el diseño de aplicaciones orientadas a
objetos. Primero es importante aprender la filosofı́a y después el lenguaje. Solo
hay una filosofı́a y varios lenguaje. En POO se esta hablando de una nueva forma
de pensar acerca del proceso de descomposición de problemas y de desarrollo de
soluciones de programación. Por ejemplo, considere el siguiente ejemplo, un objeto
cliente (persona) desea comprar un objeto automóvil. El objeto automóvil se en-
cuentra en un objeto agencia, la agencia contiene varios objetos automóviles en un
objeto almacén. Para comprar un objeto automóvil se tiene que hablar un objeto
vendedor (que también es una persona).
Un lenguaje no orientado a objetos como Pascal o C basan su funcionamiento
en el concepto de función o procedimiento. En en caso de los lenguajes orientados
a objetos, el elemento básico no son las funciones son los objetos. Un Objeto es
la representación de un concepto y contiene toda la información para abstraerlo:
datos que describen sus atributos (estado) y operaciones que describen sus com-
portamientos, lo que se puede realizar el objeto.

3
2.1. Conceptos básicos
Objeto
Un objeto no es más que un conjunto de variables (o datos) y métodos (o
funciones) relacionados entre sı́. Los objetos en programación se usan para
modelar objetos o entidades del mundo real. Un objeto es, por tanto, la
representación ver Figura 2.1 en un programa de un concepto.

Atributos
Métodos

Figura 2.1: Representación de un objeto.

Las variables en el objeto se conocen formalmente como variables instancia,

variables miembro o atributos; estas contienen el estado de un objeto particular
y, en programación orientada a objetos, un objeto particular se denomina una
instancia. Los métodos se denominan formalmente métodos instancia o métodos
miembro. La Figura 2.2 es la representación de un objeto persona. Cada atributo
de la persona tiene un valor que definen el estado del objeto.

4
 Figura 2.2: Representación de un objeto persona

Ejercicio
Cómo representar los siguientes conceptos como objetos:

• Alumno

• Libro

• Botón (en programación)

Clase
Una clase (clase regular o clase concreta) es una plantilla que define las
variables y los métodos que son comunes para todos los objetos de un cierto
tipo. Un objeto particular se conoce como una instancia de una clase.

5
 Figura 2.3: Representación de una clase Automóvil.

Usando el lenguaje de programación Java la representación de una clase Au-

tomóvil se puede realizar como se muestra en el Código 2.1. Las variables al inicio
(lı́neas 3-6) son los atributos de la clase y sus comportamientos son los métodos
se definen en las lı́neas 14-37. El bloque de código que tiene el mismo nombre que
la clase (lı́neas 8-13) se conoce como el constructor de la clase, el cual sirve para
inicializar el objeto, por ejemplo, asignar valores a los atributos.
1 c l a s s Automovil {
2

3 S t r i n g marca ;
4 S t r i n g modelo ;
5 int anio ;
6 Color c o l o r ;
7

8 p u b l i c Automovil ( S t r i n g marca , S t r i n g modelo , i n t anio , C o l o r c o l o r

){
9 t h i s . marca= marca ;
10 t h i s . modelo=modelo ;
11 t h i s . a n i o=a n i o ;
12 t h i s . c o l o r=c o l o r ;
13 }
14 v o i d setMarca ( S t r i n g marca ) {
15 t h i s . marca=marca ;
16 }

6
17 S t r i n g getMarca ( ) {
18 r e t u r n marca ;
19 }
20 v o i d setModelo ( S t r i n g modelo ) {
21 t h i s . modelo=modelo ;
22 }
23 S t r i n g getModelo ( ) {
24 r e t u r n modelo ;
25 }
26 void setAnio ( i n t anio ) {
27 t h i s . a n i o=a n i o ;
28 }
29 S t r i n g getAnio ( ) {
30 return anio ;
31 }
32 void setColor ( i n t c o l o r ) {
33 t h i s . c o l o r=c o l o r ;
34 }
35 Color getColor ( ) {
36 return color ;
37 }
38 }

Código 2.1: Representación de una clase Automóvil en Java.

2.2. Interacción entre objetos

Los objetos interactúan por medio de mensajes. Un objeto X le envı́a un men-
saje un objeto Y invocando (llamando) alguno de los métodos (comportamiento
de Y)

7
2.3. Relaciones entre clases
Las relaciones entre clases son fundamentales para modelar cómo diferentes
entidades interactúan o se asocian entre sı́. Estas relaciones son esenciales para la
creación de diseños de software robustos y mantenibles. Las principales relaciones
entre clases en POO son:

• Asociación: Esta relación implica que una clase conoce a otra y puede inter-
actuar con ella. Las asociaciones pueden ser unidireccionales (solo una clase
conoce a la otra) o bidireccionales (ambas clases se conocen mutuamente).

• Agregación: Es un tipo especial de asociación que representa una relación

”tiene-un.o ”parte-de.entre dos clases, donde una clase es un contenedor y la
otra es un contenido. Sin embargo, el contenido puede existir independien-
temente del contenedor.

• Composición: Es una forma más fuerte de agregación donde la clase con-

tenida no puede existir independientemente de la clase contenedora. Cuando
la clase contenedora es destruida, también lo son sus contenidos.

• Herencia: Esta relación se da cuando una clase (subclase) hereda carac-

terı́sticas (atributos y métodos) de otra clase (superclase). La herencia per-
mite la reutilización de código y la creación de jerarquı́as de clases.

• Dependencia: Se produce cuando una clase depende de otra para su fun-

cionamiento, pero esta relación es menos fuerte que la asociación. En la
dependencia, un cambio en una clase puede afectar a la otra.

• Realización: Se da cuando una clase implementa una interfaz. La clase

que implementa la interfaz se compromete a implementar todos los métodos
definidos en la interfaz.

2.3.1. Asociación
La Figura 2.4 muestra un ejemplo de una relación de asociación entre las clases
Automovil y TarjetaCirculacion. La linea dado que no tiene sentido (flecha) se dice

8
 que representa una relación bidireccional. Además, los números al extremos de la
linea representa la multiplicidad o cardinalidad de la relación, es decir, cuántos
objetos de un tipo están relacionados con cuántos del otro tipo. La implementación
de esta relación en Java se muestra en el Código 2.2.

Automovil TarjetaCirculacion

1
1

Figura 2.4: Relación de asociación.

1 public class TarjetaCirculacion {

2

3 Automovil a u t o m o v i l ;
4

6 }
7

8 p u b l i c c l a s s Automovil {
9

10 TarjetaCirculacion tarjetaCirculacion ;
11

12 }

Código 2.2: Implementación de la relación de asociación en Java

2.3.2. Agregación
La Figura 2.5 muestra un ejemplo de una relación de agregación entre las
clases Automovil y Motor. El rombo vacı́o representa la relación del contenedor
(Automovil) y su contenido (Motor). La implementación de esta relación en Java se
muestra en el Código 2.3. Es importante resaltar en este ejemplo que si se destruye
el Automovil el Motor no se destruye (se puede reutilizar).

9
 Automovil Motor

Figura 2.5: Relación de agregación.

1 p u b l i c c l a s s Motor {
2 // A t r i b u t o s y metodos d e l motor
3 }
4

5 p u b l i c c l a s s Automovil {
6 Motor motor ;
7

8 Automovil ( Motor motor ) {

9 t h i s . motor = motor ;
10 }
11 }
12

13 // Uso
14 Motor motor = new Motor ( ) ;
15 Automovil c o c h e = new Automovil ( motor ) ;

Código 2.3: Implementación de la relación de agregación en Java

2.3.3. Composición
La Figura 2.6 muestra un ejemplo de una relación de composición entre las
clases Automovil y Motor. El rombo lleno representa la relación del contenedor
(Automovil) y su contenido (Motor). La implementación de esta relación en Java
se muestra en el Código 2.3. Es importante resaltar en este ejemplo que si se
destruye el Automovil el Motor también (no se puede reutilizar).

10
 Automovil Motor

Figura 2.6: Relación de composición.

1 p u b l i c c l a s s Motor {
2 // A t r i b u t o s y metodos d e l motor
3 }
4

5 p u b l i c c l a s s Automovil {
6 Motor motor ;
7

8 Automovil ( ) {
9 t h i s . motor = new Motor ( ) ;
10 }
11 }
12

13 // Uso
14 Automovil c o c h e = new Automovil ( ) ;

Código 2.4: Implementación de la relación de composición en Java

2.3.4. Herencia
La Figura 2.7 muestra un ejemplo de una relación de herencia entre las clases
TransporteTerrestre y Automovil. El flecha representa la relación de la clase pa-
dre (TransporteTerrestre) y su clase hija (Automovil). La implementación de esta
relación en Java se muestra en el Código 2.5. .

11
 TransporteTerrestre

Automovil

Figura 2.7: Relación de herencia.

1 public class TransporteTerrestre {

2

3 }
4 p u b l i c c l a s s Automovil extends TransporteTerrestre {
5

6 }
7 // Uso
8 Automovil c o c h e = new Automovil ( ) ;

Código 2.5: Implementación de la relación de composición en Java

2.3.5. Dependencia
La Figura 2.8 muestra un ejemplo de una relación de dependencia entre las
clase Automovil y la clase Conductor. La implementación de esta relación en Java
se muestra en el Código 2.6. .

Automovil Conductor

Figura 2.8: Relación de dependencia.

1 p u b l i c c l a s s Conductor {
2

12
 3 }
4 p u b l i c c l a s s Automovil {
5 p u b l i c v o i d a s i g n a r C o n d u c t o r ( Conductor c o n d u c t o r ) {
6 // L o g i c a para a s i g n a r e l c o n d u c t o r a l a u t o m o v i l
7 }
8 }
9 // Uso
10 Automovil c o c h e = new Automovil ( ) ;

Código 2.6: Implementación de la relación de dependencia en Java

2.3.6. Realización
La Figura 2.9 muestra un ejemplo de una relación de realización entre las clase
Vehiculo y la clase Automovil. La implementación de esta relación en Java se
muestra en el Código 2.7.

Vehiculo

Automovil

Figura 2.9: Relación de realización.

1 public i n t e r f a c e Vehiculo {
2 void arrancar ( ) ;
3 void detener ( ) ;
4 void a c e l e r a r ( ) ;
5 }
6 p u b l i c c l a s s Automovil implements V e h i c u l o {
7

13
 8 @Override
9 public void arrancar ( ) {
10 System . out . p r i n t l n ( ” El a u t o m o v i l e s t a a r r a n c a n d o . ” ) ;
11 }
12

13 @Override
14 public void detener ( ) {
15 System . out . p r i n t l n ( ” El a u t o m o v i l s e ha d e t e n i d o . ” ) ;
16 }
17

18 @Override
19 public void a c e l e r a r ( ) {
20 System . out . p r i n t l n ( ” El a u t o m o v i l e s t a a c e l e r a n d o . ” ) ;
21 }
22

23 // Otros metodos y a t r i b u t o s e s p e c i f i c o s de Automovil

24 }
25 // Uso
26 Automovil c o c h e = new Automovil ( ) ;

Código 2.7: Implementación de la relación de realización en Java

14
Capı́tulo 3

Herencia

Uno de los pilares de la Programación Orientada a Objetos es la Herencia.

La herencia la vimos brevemente en el Capı́tulo 2, no obstante entraremos más a
detalle en este capitulo.

Herencia
La herencia es un principio fundamental de la Programación Orientada a
Objetos (POO) que permite a una clase (llamada subclase o clase hija)
heredar propiedades y métodos de otra clase (conocida como superclase o
clase padre).

La herencia permite definir una clase en términos de otra, lo cual hace más
fácil el mantenimiento y desarrollo de una aplicación. También proporciona una
oportunidad para la reutilización de código y con ellos tener un desarrollo más
rápido. Cuando un clase X hereda de otra clase Y, la clase X hereda todos sus
atributos y comportamiento. La clase X se conoce como clase hija o clase derivada
y la clase X como super clase o clase padre.

3.1. Tipos de herencia

La herencia se puede clasificar en:

15
 1. Simple (Figura 3.1a)

2. Multi-nivel (Figura 3.1b)

3. Jerárquica (Figura 3.1c)

4. Múltiple (Figura 3.1d)

Figura 3.1: Tipos de herencia

3.1.1. Herencia simple

En esta herencia una clase simplemente hereda de otra. La Herencia simple en
Java se puede representar como se muestra en el ejemplo del Código 3.1.

1 c l a s s Automovil {
2

3 }
4 c l a s s S e n t r a e x t e n d s Automovil {
5

6 }

Código 3.1: Herencia simple en Java.

3.1.2. Herencia multi-nivel

En esta herencia hay diferentes niveles (descendientes). La Herencia multi-nivel
en Java se puede representar como se muestra en el ejemplo del Código 3.2.

16
 1 c l a s s Automovil {
2

3 }
4

5 c l a s s Rio e x t e n d s Automovil {
6

7 }
8

9 c l a s s RioHatchback e x t e n d s Rio {
10

11 }

Código 3.2: Herencia multi-nivel en Java.

3.1.3. Herencia jerárquica

En este herencia al menos dos clases en un mismo nivel heredan de otra. La
Herencia jerárquica en Java se puede representar como se muestra en el ejemplo
del Código 3.3.
1 c l a s s Automovil {
2

3 }
4

5 c l a s s Rio e x t e n d s Automovil {
6

7 }
8

9 c l a s s S e n t r a e x t e n d s Automovil {
10

11 }

Código 3.3: Herencia jerárquica en Java.

17
 3.1.4. Herencia múltiple
En esta herencia una clase hereda de 2 o más clases. En Java no es posible la
herencia múltiple debido a un problema de ambigüedad. Considere el ejemplo de
la Figura 3.2. La clase A hereda de la clase B y C sus comportamientos. ¿Cuál
método f hereda A?.

Figura 3.2: Ambigüedad en la herencia múltiple.

La herencia en el lenguaje de programación Java se puede realizar de 3 formas

en general:

1. Una clase hereda de una clase.

2. Una clase implementa una interfaz.

3. Una interfaz hereda de otra interfaz.

3.2. Interfaces en Java

Una interfaz es una especie de plantilla para la construcción de clases. Normal-
mente una interfaz se compone de un conjunto de declaraciones de cabeceras de
métodos (sin implementar) que especifican un protocolo de comportamiento para
una o varias clases. Además, una clase puede implementar una o varias interfaces.
El ejemplo del Código 3.4 muestra la definición de una interface en Java. Como se
observa, se tienen los métodos sin implementar. Una clase al utilizar la interface
esta obligada a implementar sus métodos (ver Código 3.5). Para implementar una
interface una clase en Java utiliza la palabra reservada implements.

1 public interface Clinica {

2

3 void r e g i s t r a r P a c i e n t e ( Paciente e ) ;

18
 4 Paciente eliminarRegistro ( int expediente ) ;
5 void mostrarPacientes ( ) ;
6 int getTotalPacientes () ;
7 void citasEdad ( i n t i n i c i o , i n t f i n ) ;
8 void mostrarPorEspecialidad ( Especialidad e ) ;
9 v o i d mostrarAgrupacion ( ) ;
10 void modificarPaciente ( i n t expediente ) ;
11 }

Código 3.4: Ejemplo de una interface en Java.

1 p u b l i c c l a s s Pegaso implements C l i n i c a {
2

3 p u b l i c Pegaso ( ) {
4

5 }
6

7 @Override
8 public void r e g i s t r a r P a c i e n t e ( Paciente e ) {
9

10 }
11

12 i n t buscarPorExpediente ( i n t expediente ) {
13 r e t u r n −1;
14 }
15

16 @Override
17 public Paciente eliminarRegistro ( int expediente ) {
18 return null ;
19 }
20

21 @Override
22 public void mostrarPacientes ( ) {
23

19
24 }
25

26 @Override
27 public int getTotalPacientes () {
28 r e t u r n −1;
29 }
30

31 @Override
32 public void citasEdad ( i n t i n i c i o , i n t f i n ) {
33

34 }
35

36 @Override
37 public void mostrarPorEspecialidad ( Especialidad es ) {
38

39 }
40

41 @Override
42 p u b l i c v o i d mostrarAgrupacion ( ) {
43

44 }
45

46 @Override
47 public void modificarPaciente ( i n t expediente ) {
48

49 }
50

51 }

Código 3.5: Implementación de la interface Clı́nica.

20
 3.3. Clases abstractas
Clase abstracta
Una clase abstracta es un tipo de clase que no puede ser instanciada direc-
tamente, es decir, no se pueden crear objetos de ella de manera directa.

El principal propósito de una clase abstracta es servir como clase base para
otras clases. Las clases abstractas se utilizan para definir interfaces comunes y
funcionalidades parciales que pueden ser compartidas y extendidas por sus clases
derivadas.
En Java una clase abstracta es una clase que se declara como abstracta y puede,
o no, tener métodos abstractos. Las clases abstractas no pueden ser instanciadas,
pero se pueden crear instancias por medio de clases derivadas de ellas. Un método
abstracto es un método que se declara sin una implementación. El Código 3.6
muestra la definición de una clase abstracta en Java llamada Banco. Usando esta
clase se definen las clases HSBC y la clase Banorte. Al ser la clase Banco abstracta,
es posible crear instancias de HSBC y Banorte pero no de Banco.
El siguiente ejemplo muestra el uso de clases abstractas:

1 a b s t r a c t c l a s s Banco{
2 abstract int getTasaInteres () ;
3 }
4 c l a s s HSBC e x t e n d s Banco{
5 int getTasaInteres () {
6 return 7;
7 }
8 }
9 c l a s s Banorte e x t e n d s Banco{
10 int getTasaInteres () {
11 return 8;
12 }
13 }
14

15 c l a s s TestBanco {

21
16 p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) {
17 Banco b ;
18 b=new HSBC( ) ;
19 System . out . p r i n t l n ( ” Tasa de i n t e r e s : ”+b . g e t T a s a I n t e r e s ( )+” \%”
);
20 b=new Banorte ( ) ;
21 System . out . p r i n t l n ( ” Tasa de i n t e r e s : ”+b . g e t T a s a I n t e r e s ( )+” \%”
);
22 }
23 }

Código 3.6: Definición de una clase abstracta Banco y creación de instancias de

esta por medio de herencia.

Otro ejemplo se muestra en los Códigos 3.7 y 3.8. Se define la clase abstracta
Persona y se crea la clase Paciente mediante una relación de herencia con Persona.
1 p u b l i c a b s t r a c t c l a s s Persona {
2

3 p r i v a t e S t r i n g nombre ;
4 private String genero ;
5

6 p u b l i c Persona ( S t r i n g nm, S t r i n g gen ) {

7 nombre=nm;
8 g e n e r o=gen ;
9 }
10

11 public abstract void getTrabajo ( ) ;

12

13 @Override
14 public String toString () {
15 r e t u r n ”Nombre=”+nombre+” : : Genero=”+g e n e r o ;
16 }
17

18 p u b l i c v o i d cambiarNombre ( S t r i n g nuevoNombre ) {

22
19 nombre = nuevoNombre ;
20 }
21 }

Código 3.7: Clase abstracta Persona.

1 p u b l i c c l a s s Empleado e x t e n d s Persona {
2

3 p r i v a t e i n t numEmpleado ;
4

5 p u b l i c Empleado ( S t r i n g nm, S t r i n g gen , i n t i d ) {

6 s u p e r (nm, gen ) ;
7 numEmpleado=i d ;
8 }
9

10 @Override
11 public void getTrabajo ( ) {
12 .
13 .
14 .
15 }
16

17 p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) {
18 .
19 .
20 .
21 .
22 }
23

24 }

Código 3.8: Clase Paciente que hereda de una clase abstracta Persona

23
Capı́tulo 4

Encapsulamiento y ocultamiento

4.1. Encapsulamiento
Encapsulamiento
El encapsulamiento es unos de los conceptos pilares en la programación
orientada a objetos. Se define como el proceso de agrupar o encerrar datos
y/o funciones para desempeñar acciones sobre estos como si fueran una solo
unidad ⇒ empaquetar información.

En Java la encapsulación se puede presentar de diferentes formar en la progra-

mación orientada a objetos. Entre las que podemos destacar:

• Por medio de métodos

• Por medio de clases

• Por medio de paquetes

4.1.1. Por medio de métodos

Los métodos encapsulan operaciones/cálculos. Por ejemplo, si se implementa
el método int calcular factorial(int n) se encapsula los productos que se requieren
para la operación factorial.

24
 4.1.2. Por medio de clases
Las clases encapsulan atributos y comportamientos. El ejemplo del Código 4.1
muestra la clase Persona en Lenguaje Java, la cual encapsula los atributos nombre,
apellido y fnacimiento y encapsula los comportamientos getNombre, setNombre,
getApellido, setApellido, getFnacimiento y setFnacimiento.

1 c l a s s Persona {
2

3 S t r i n g nombre ;
4 String apellido ;
5 Fecha fnacimiento ;
6

7 Persona ( ) {
8 }
9 Persona ( S t r i n g nombre , S t r i n g a p e l l i d o , Fecha f n a c i m i e n t o ) {
10 t h i s . nombre = nombre ;
11 this . apellido = apellido ;
12 t h i s . f n a c i m i e n t o=f n a c i m i e n t o ;
13 }
14 S t r i n g getNombre ( ) {
15 r e t u r n nombre ;
16 }
17 v o i d setNombre ( S t r i n g nombre ) {
18 t h i s . nombre = nombre ;
19 }
20 String getApellido () {
21 return apellido ;
22 }
23 void s e t A p e l l i d o ( String a p e l l i d o ) {
24 this . apellido = apellido ;
25 }
26 Fecha g e t F n a c i m i e n t o ( ) {
27 return fnacimiento ;

25
28 }
29 v o i d s e t F n a c i m i e n t o ( Fecha f n a c i m i e n t o ) {
30 this . fnacimiento = fnacimiento ;
31 }
32 }

Código 4.1: Representación de encapsulamiento en Java por medio de una clase.

4.1.3. Por medio de paquetes

Un Paquete es un contenedor de clases (carpeta) que permite agrupar las distin-
tas partes de un programa y que por lo general tiene una funcionalidad y elementos
comunes, definiendo la ubicación de dichas clases en un directorio de estructura
jerárquica. En la Figura 4.1 se muestran ocho paquetes en Java: java, java.awt,
java.awt.event, javax, javax.swing, proyecto, proyecto.gui y proyecto.main. Cuan-
do en un paquete hay otros paquetes se utiliza la notación . para hacer referencia
al mismo (y con ellos se conoce la ruta del paquete). Como se observa en esta
figura, hay paquetes que tienen clases y otros paquetes. El paquete java.awt.event
tiene las clases ActionEvent.java y ActionListener.java y esta dentro del paquete
java.awt.

26
 Figura 4.1: Paquetes en un proyecto.

4.2. Ocultamiento de información

Ocultamiento
El ocultamiento es hacer inaccesible ciertos detalles que no deben afectar las
otras partes del sistema.

Hablando de Java, esta tecnologı́a proporciona modificadores que representan

diferentes niveles de acceso:

27
 Modificador Clase Paquete Sub-Clase Otro
public ✓ ✓ ✓ ✓
protected ✓ ✓ ✓
no modifier ✓ ✓
private ✓

Tabla 4.1: Modificadores de ocultamiento de información en Java.

• public: cualquier elemento (por ejemplo un atributo o un método) que sea

public se puede acceder desde la misma clase, desde una otra clase en el
mismo paquete (carpeta), desde otra clase en otro paquete.

• protected: cualquier elemento (por ejemplo un atributo o un método) que

sea protected se puede acceder desde la misma clase, desde una otra clase
en el mismo paquete (carpeta), desde otra clase en otro paquete siempre y
cuando exista relación de herencia.

• sin modificador: cualquier elemento (por ejemplo un atributo o un método)

que no tenga algún modificador se puede acceder desde la misma clase o
desde otra clase en el mismo paquete (carpeta).

• private: cualquier elemento (por ejemplo un atributo o un método) que sea

private se puede acceder únicamente desde la misma clase.

El ejemplo del Código 4.2 se muestra un ejemplo en Java donde se aplican los
modificadores private en los atributos de la clase Persona, y el modificador public
en sus métodos. Lo anterior garantiza que los atributos solo puedan ser accedidos
únicamnete dentro de la clase y los métodos desde cualquier parte (desde la clase,
desde otra clase en el mismo paquete, o bien desde una clase en otro paquete.).
1

2 p u b l i c c l a s s Persona {
3

4 p r i v a t e S t r i n g nombre ;
5 private String apellido ;

28
 6 p r i v a t e Fecha fnacimiento ;
7

8 p u b l i c Persona ( ) {
9 }
10 p u b l i c Persona ( S t r i n g nombre , S t r i n g a p e l l i d o , Fecha f n a c i m i e n t o ) {
11 t h i s . nombre = nombre ;
12 this . apellido = apellido ;
13 t h i s . f n a c i m i e n t o=f n a c i m i e n t o ;
14 }
15 p u b l i c S t r i n g getNombre ( ) {
16 r e t u r n nombre ;
17 }
18 p u b l i c v o i d setNombre ( S t r i n g nombre ) {
19 t h i s . nombre = nombre ;
20 }
21 public String getApellido () {
22 return apellido ;
23 }
24 public void s e t A p e l l i d o ( String a p e l l i d o ) {
25 this . apellido = apellido ;
26 }
27 p u b l i c Fecha g e t F n a c i m i e n t o ( ) {
28 return fnacimiento ;
29 }
30 p u b l i c v o i d s e t F n a c i m i e n t o ( Fecha f n a c i m i e n t o ) {
31 this . fnacimiento = fnacimiento ;
32 }
33 }

Código 4.2: Clase Persona en Java con modificadores private y public para definir
niveles de ocultamiento.

29
Capı́tulo 5

Polimorfismo

Polimorfismo
El polimorfismo en la Programación Orientada a Objetos (POO) es un con-
cepto fundamental que permite a los objetos de diferentes clases ser tratados
como objetos de una clase común.

El polimorfismo se pude dividir en 3 tipos:

1. Polimorfismo de Inclusión: Refiere a la habilidad de objetos de diferentes

clases derivadas de una clase base para ser tratados como objetos de la clase
base.

2. Polimorfismo Paramétrico: Uso de tipos genéricos para permitir que una

función o clase trabaje con diferentes tipos de datos.

3. Polimorfismo de Sobrecarga: Refiere a la capacidad de tener varios métodos

con el mismo nombre pero con diferentes firmas o parámetros.

5.1. Polimorfismo de Inclusión (o Subtipado)

Es el tipo de polimorfismo más comúnmente asociado con POO. Se refiere a la
capacidad de una referencia a una clase base para referenciar a un objeto de una
clase derivada, permitiendo que el objeto derivado sea tratado como si fuera del

30
 tipo de la clase base. Este tipo de polimorfoismo se logra mediante la herencia.
Las clases derivadas extienden la clase base y pueden sobrescribir sus métodos.
En tiempo de ejecución, se invocan los métodos de la clase derivada, aunque la
referencia sea del tipo de la clase base.
En el Código 5.1 se tiene una clase base Persona y clases derivadas como
Alumno y Profesor. Si Persona tiene un método mostrarDetalles, las clases Profesor
y Alumno pueden sobrescribir este método para hacer mostrar detalles especı́ficos.
Una referencia de tipo Persona puede apuntar a un objeto Profesor o Alumno, y
mostrarDetalles invocará el método correspondiente al tipo real del objeto.
1 p u b l i c c l a s s Persona {
2 p r i v a t e S t r i n g nombre ;
3

4 p u b l i c Persona ( S t r i n g nombre ) {
5 t h i s . nombre = nombre ;
6 }
7

8 public void mostrarDetalles ( ) {

9 System . out . p r i n t l n ( ”Nombre : ” + nombre ) ;
10 }
11 }
12 p u b l i c c l a s s Alumno e x t e n d s Persona {
13 private String matricula ;
14

15 p u b l i c Alumno ( S t r i n g nombre , S t r i n g m a t r i c u l a ) {
16 s u p e r ( nombre ) ;
17 this . matricula = matricula ;
18 }
19

20 @Override
21 public void mostrarDetalles ( ) {
22 super . mostrarDetalles () ;
23 System . out . p r i n t l n ( ” M a t r i c u l a : ” + m a t r i c u l a ) ;

31
24 }
25 }
26

27 p u b l i c c l a s s P r o f e s o r e x t e n d s Persona {
28 p r i v a t e i n t numEmpleado ;
29

30 p u b l i c P r o f e s o r ( S t r i n g nombre , i n t numEmpleado ) {
31 s u p e r ( nombre ) ;
32 t h i s . numEmpleado =numEmpleado ;
33 }
34

35 @Override
36 public void mostrarDetalles ( ) {
37 super . mostrarDetalles () ;
38 System . out . p r i n t l n ( ”Num. Empleado : ” + numEmpleado ) ;
39 }
40 }

Código 5.1: Ejemplo de polimorfismo de inclusión.

5.2. Polimorfismo Paramétrico

Se refiere a la capacidad de una función, método o clase para operar con cual-
quier tipo de dato. Este es comúnmente implementado a través de tipos genéricos.
Los genéricos permiten escribir un código que puede trabajar con cualquier tipo de
datos, donde el tipo exacto de dato se especifica como un parámetro. En tiempo
de compilación, se generan versiones del código para los tipos especı́ficos que se
usan.
En Java, cuando definimos una nueva clase, debemos conocer el tipo de dato
con el que trabajaremos. Si queremos realizar una operación especı́fica dentro de
esta nueva clase, sea cual sea el tipo de datos que va a recibir, podemos hacer uso
de los tipos genéricos (ver Código 5.2). Un tipo genérico es una clase o interfaz
genérica que es parametrizada sobre tipos. Este tipo genérico asumirá el tipo de

32
 dato que realmente le pasaremos a la clase (o método). Para especificar los tipos
genéricos se utilizan los operados diamante, es decir, el tipo se encierra entre los
operadores mayor y menor que (Código 5.2, lı́nea 1).
1 c l a s s C l a s e G e n e r i c a <T> {
2 T obj ;
3

4 p u b l i c C l a s e G e n e r i c a (T o ) {
5 obj = o ;
6 }
7

8 public void classType ( ) {

9 System . out . p r i n t l n ( ” El t i p o de T e s ” + o b j . g e t C l a s s ( ) . getName ( ) )
;
10 }
11 }
12

13 p u b l i c c l a s s App {
14 p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) {
15 // Creamos una i n s t a n c i a de C l a s e G e n e r i c a para I n t e g e r .
16 C l a s e G e n e r i c a <I n t e g e r > i n t O b j = new C l a s e G e n e r i c a <I n t e g e r >(88) ;
17 intObj . classType ( ) ;
18

19 // Creamos una i n s t a n c i a de C l a s e G e n e r i c a para S t r i n g .

20 C l a s e G e n e r i c a <S t r i n g > s t r O b j = new C l a s e G e n e r i c a <S t r i n g >(” Test ” ) ;
21 strObj . classType () ;
22

23 }
24 }

Código 5.2: Ejemplo de polimorfismo paramétrico.

El tipo de T es java.lang.Integer
El tipo de T es java.lang.String

33
 Hay que tener en cuenta que los genéricos de java solo funcionan con objetos.
Existen una serie de convenciones para nombrar a los genéricos:

• E – Element (usado bastante por Java Collections Framework)

• K – Key (Llave, usado en mapas)

• N – Number (para números)

• T – Type (Representa un tipo, es decir, una clase)

• V – Value (representa el valor, también se usa en mapas)

• S,U,V etc. – usado para representar otros tipos.

El Código 5.3 muestra un ejemplo del uso de tipos genéricos mediante la defi-
nición de un almacén. El almacén puede contener cualquier tipo que se especifique
mediante en los operadores diamante.
1 p u b l i c c l a s s Almacen<E> {
2

3 p u b l i c s t a t i c f i n a l i n t CAPACIDAD=5;
4 p r i v a t e Object [ ] bodega= new Object [CAPACIDAD ] ;
5 p r i v a t e i n t i n d e x =0;
6

7 v o i d a g r e g a r (E e ) {
8 i f ( index<CAPACIDAD) {
9 bodega [ i n d e x ]= e ;
10 i n d e x++;
11 }
12 }
13 @Override
14 public String toString () {
15 S t r i n g tmp=” ” ;
16 int i ;
17 f o r ( i =0; i <i n d e x ; i ++)
18 tmp = tmp +bodega [ i ] ;

34
19 r e t u r n tmp ;
20

21 }
22 }
23 public class Principal {
24

25 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
26 Almacen<Automovil> b1 = new Almacen<Automovil >() ;
27

28 Almacen<Libro> b2 = new Almacen<Libro >() ;

29

30 b1 . a g r e g a r ( new Automovil ( ” Kia ” , ” F o r t e ” , 2 0 1 7 , 3 . 5 , 4 ) ) ;

31 b1 . a g r e g a r ( new Automovil ( ” Ford ” , ” Focus ” , 2 0 1 6 , 3 . 6 , 6 ) ) ;
32

33 b2 . a g r e g a r ( new L i b r o ( ” Juan ” , ” Cloud ” , new Fecha ( 1 2 , 1 1 , 2 0 1 3 ) , ”

Mexico ” , ” 3543534 ” ) ) ;
34 b2 . a g r e g a r ( new L i b r o ( ” Pedro ” , ”GPU” , new Fecha ( 5 , 6 , 2 0 1 6 ) , ” Mexico
” , ” 223456 ” ) ) ;
35

36 System . out . p r i n t l n ( b1 ) ;
37 System . out . p r i n t l n ( b2 ) ;
38 }
39

40 }

Código 5.3: Almacen mediante polimorfismo paramétrico.

5.3. Polimorfismo de Sobrecarga

Implica tener múltiples funciones o métodos con el mismo nombre, pero con
diferentes listas de parámetros (diferente número o tipos de parámetros. El com-
pilador o el intérprete distingue entre estas funciones o métodos en base a la firma

35
 de los parámetros. Es una forma de polimorfismo que se resuelve en tiempo de
compilación.
En Java podemos encontrar la sobrecarga en:

• Constructores

• Métodos

5.3.1. Ejemplo: Sobrecarga de constructores

2 p u b l i c c l a s s Fecha {
3 private int dia ;
4 p r i v a t e i n t mes ;
5 private int anio ;
6

7 Fecha ( i n t dia , i n t mes , i n t a n i o ) {

8 t h i s . d i a=d i a ;
9 t h i s . mes=mes ;
10 t h i s . a n i o=a n i o ;
11 }
12 Fecha ( S t r i n g f e c h a ) {
13

14 String delimitador = ” [ / ] ” ;
15 String [ ] tokens = fecha . s p l i t ( delimitador ) ;
16

17 d i a=I n t e g e r . p a r s e I n t ( t o k e n s [ 0 ] ) ;
18 mes=I n t e g e r . p a r s e I n t ( t o k e n s [ 1 ] ) ;
19 a n i o=I n t e g e r . p a r s e I n t ( t o k e n s [ 2 ] ) ;
20

21 }
22 @Override
23 public String toString () {

36
24 r e t u r n ” Fecha [ d i a=” + d i a + ” , mes=” + mes + ” , a n i o=” + a n i o +
”]”;
25 }
26 }

Código 5.4: Sobrecarga de constructores

5.3.2. Ejemplo: Sobrecarga de métodos

1 public c l a s s Calculadora {
2

3 i n t sumar ( i n t a , i n t b ) {
4 r e t u r n a+b ;
5 }
6 d o u b l e sumar ( d o u b l e a , d o u b l e b ) {
7 r e t u r n a+b ;
8 }
9 int restar ( int a , int b) {
10 r e t u r n a−b ;
11 }
12 double r e s t a r ( double a , double b) {
13 r e t u r n a−b ;
14 }
15 int multiplicar ( int a , int b) {
16 r e t u r n a∗b ;
17 }
18 double m u l t i p l i c a r ( double a , double b) {
19 r e t u r n a∗b ;
20 }
21 }

Código 5.5: Sobrecarga de métodos

37
Acrónimos

GG Gramática de Grafos.

GGRH Gramática de Grafos mediante el Reemplazo de Hiperaristas.

GPU Graphics Processing Unit.

LPV Lenguaje de Programación Visual.

MPI Message Passing Interface.

MPMD Multiple Program Multiple Data.

PVM Parallel Virtual Machine.

SPMD Single Program Multiple Data.

VPPE Visual Parallel Programming Environment.

VPPL Visual Parallel Programming Languaje.

38
 Acrónimos

39