Informe Herencia

ÍNDICE
HERENCIA ...................................................................................................................... 5
1. INTRODUCCIÓN .................................................................................................... 5
2. OBJETIVO DE LA PRÁCTICA .............................................................................. 5
2.1. OBJETIVO GENERAL ..................................................................................... 5
2.2. OBJETIVOS ESPECÍFICOS ............................................................................ 5
3. METODOLOGÍA ..................................................................................................... 6
3.2. DESARROLLO ................................................................................................. 8
4. RECURSOS MATERIALES Y EQUIPOS ............................................................. 9
5. DESCRIPCIÓN Y DESARROLLO DE LA PRÁCTICA ..................................... 10
5.1. FUNDAMENTOS ........................................................................................... 10
5.1.2. CLASES DERIVADAS ........................................................................... 12
5.2. CONTROL ACCESO ...................................................................................... 15
5.2.1. DEFINICIÓN CONTROL DE ACCESO ................................................ 15
5.2.2. ACCESIBILIDAD Y VISIBILIDAD EN HERENCIA ........................... 17
5.3. SOBREESCRITURA, CONSTRUCTORES Y POLIMORFISMO ............... 20
5.3.1. SOBREESCRITURA ............................................................................... 20
5.3.2. SOBRECARGA DE MÉTODOS (OVERRIDING) ................................ 21
5.3.3. REGLAS PARA LA SOBREESCRITURA ............................................ 22
5.4. CONSTRUCTORES ....................................................................................... 23
5.4.1. DEFINICIÓN CONSTRUCTOR ............................................................. 23
5.4.2. CONSTRUCTOR POR DEFECTO ......................................................... 24
5.4.3. CONSTRUCTOR CON PARÁMETROS ............................................... 24
5.5. SOBRECARGA............................................................................................... 26
5.6. DESTRUCTOR ............................................................................................... 27
5.7. POLIMORFISMO ........................................................................................... 28
5. RESULTADOS Y CONCLUSIONES ................................................................... 29
6. PRÁCTICA LABORATORIO ............................................................................... 30
7.BIBLIOGRAFÍA ......................................................................................................... 51
ÍNDICE DE TABLAS
Tabla 1: Recursos Humanos ............................................................................................. 9

Tabla 2: Recursos Económicos ........................................................................................ 9
Tabla 3: Recursos de red .................................................................................................. 9
Tabla 4: Control de accesos ............................................................................................ 16
Tabla 5: Nivel de accesos ............................................................................................... 16
Tabla 6: Visibilidad de elementos de clase .................................................................... 17
Tabla 7: Acceso a variables y funciones según tipo de herencia.................................... 18
Tabla 8: Tipos de herencia y accesos que permiten ....................................................... 19
ÍNDICE DE FIGURAS
Figura 1: Investigación Cuantitativa................................................................................. 7

Figura 2: Temas de Herencia ............................................................................................ 8
Figura 3: Herencia Simple .............................................................................................. 11
Figura 4:Herencia de la clase animal. ............................................................................. 12
Figura 5: Clases Derivadas. ............................................................................................ 12
Figura 6:Accesibilidad y Visibilidad en Herencia .......................................................... 19
Figura 7: Polimorfismo en java ...................................................................................... 28
Figura 8: Interface, de una clase abstracta y 2 clases ..................................................... 29
Figura 9: Código de la Clase Padre(Persona) ................................................................. 30
Figura 10: Ejecución en la Consola de Persona ............................................................. 31
Figura 11: Ejecución en Consola de Estudiante ............................................................. 31
Figura 12: Ejecución en Consola de Docente ................................................................. 32
Figura 13:Ejecución en Consola-Salida ......................................................................... 32
Figura 14: Autores Fuente: Integrantes del Grupo ......................................................... 33
Figura 15: Ventana Principal Fuente: Integrantes del Grupo ......................................... 33
Figura 16: Opción Nuevo Fuente: Integrantes del Grupo .............................................. 34
Figura 17: Opción Cliente (Ingresar datos del cliente1) Fuente: Integrantes del Grupo 34
Figura 18: Opción Cliente (Ingresar datos del cliente1) Fuente: Integrantes del Grupo 35
Figura 19: Grabado correctamente Fuente: Integrantes del Grupo ................................ 35
Figura 20: Opción Empleado Fuente: Integrantes del Grupo ......................................... 36
Figura 21: Ingresar los datos del empleado (vendedor1) Fuente: Integrantes del Grupo36
Figura 22: Ingresar los datos del empleado (vendedor2) Fuente: Integrantes del Grupo37
Figura 23: Ingresar los datos del empleado (cajero1) Fuente: Integrantes del Grupo .... 37
Figura 24: Ingresar los datos del empleado (cajero2) Fuente: Integrantes del Grupo .... 38
Figura 26: Opción Discos (Ingresar información del disco) Fuente: Integrantes del
Grupo .............................................................................................................................. 39
Grupo .............................................................................................................................. 39
Grupo .............................................................................................................................. 40
Grupo .............................................................................................................................. 40
Figura 31: Opción Factura Fuente: Integrantes del Grupo ............................................. 41
Figura 32: Ingresar información para generar factura Fuente: Integrantes del Grupo ... 42
Figura 33: Ingresar la cantidad de discos a comprar Fuente: Integrantes del Grupo ..... 42
Figura 34: Compra agregada a la factura Fuente: Integrantes del Grupo ....................... 43
Figura 35: Ingresar la cantidad de nuevos discos a comprar Fuente: Integrantes del
Grupo .............................................................................................................................. 43
Figura 36: Compra agregada a la factura Fuente: Integrantes del Grupo ....................... 44
Figura 38: Opción Ventas (Revisar Ventas) Fuente: Integrantes del Grupo .................. 45
Figura 39: Seleccionar el número de factura (Ver factura) Fuente: Integrantes del Grupo
........................................................................................................................................ 45
Figura 40: Opción Salir Fuente: Integrantes del Grupo ................................................. 46
UNIVERSIDAD TÉCNICA DEL NORTE
FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS
CARRERA DE INGENIERÍA ELECTRÓNICA Y REDES DE COMUNICACIÓN
PROGRAMACIÓN II
TEMA:
HERENCIA
DOCENTE:
Ing. Ana Umaquinga
INTEGRANTES:
Almeida Axel
Carlosama Darwin
Chávez Royer
Navarrete Alder
Ulcuango Pablo
Ibarra – Ecuador
HERENCIA
1. INTRODUCCIÓN
La herencia crear jerarquías de clases relacionadas y reduce la cantidad de código

redundante. El soporte de la herencia es una de las propiedades que diferencia los
lenguajes orientadas objetos de los lenguajes basados en objetos y lenguajes
estructurados. La herencia es la propiedad que permite definir nuevas clases usando como
base clases ya existentes. La nueva clase (clase derivada) hereda los atributos
comportamientos que son específicos de ella. La herencia es una herramienta poderosa
que proporciona un marco adecuado para producir software fiable, comprensible, de bajo
costo, adaptable y reutilizable. (Joyanes Aguilar, Luis Zahonero, & Ignacio Martínez,
2010)(Joyanes Aguilar, Luis Zahonero, & Ignacio Martínez, 2010)
Para la recolección de información se utilizó técnicas de investigación,

metodologías, con la cual nos permitieron comprender y facilitar la estructuración de
código en la programación y dándose a conocer sobre sus jerarquías y sus métodos que
tiene incluidos en su mecanismo.
Con el desarrollo de esta guía, se impartirá la información y conocimientos

adquiridos en la materia de programación II de Carrera de Ingeniería en Electrónica y
Redes de Comunicación (CIERCOM), Universidad Técnica del Norte (UTN), con el
trabajo de cada uno de los procesos que se incluye en la metodología utilizada y con ello
poder aclarar las diferentes inquietudes del tema de herencia.
2. OBJETIVO DE LA PRÁCTICA
2.1. OBJETIVO GENERAL
Elaborar una guía práctica con estrategias metodológicas basadas en Herencia.
2.2. OBJETIVOS ESPECÍFICOS
• Definir los temas que se van a desarrollar en la guía.
• Delimitar estrategias metodológicas para la fácil comprensión tema.

• Desarrollar ejemplos prácticos para lograr un mejor desempeño en la aplicación
de Herencia.
3. METODOLOGÍA
3.1.PROPÓSITO DE INVESTIGACIÓN
3.1.1. ESTUDIOS DESCRIPTIVOS
Busca especificar propiedad, características y rasgos importantes de cualquier

fenómeno que se analice. (Hernández, Collado, & Lucio, 2003)
Los estudios descriptivos pretenden medir o recoger información de manera

independiente o conjunta sobre los conceptos o las variables a los que se refieren. Desde
luego, pueden integrar las mediciones o información de cada una de dichas variables o
conceptos para decir como es y cómo se manifiesta el fenómeno de interés.(Hernández
et al., 2003)
• VALOR
“Los descriptivos se centran en recolectar datos que muestran en un evento,

una comunidad, un fenómeno, un hecho, contexto o situación que ocurre.”
(Hernández et al., 2003)
3.1.2. ESTUDIO CORRELACIONAL
“Este tipo de estudios tiene como propósito evaluar la relación que existe entre
dos o más conceptos, categorías o variables (En un contexto en particular).”
3.1.3. ESTUDIOS EXPLICATIVOS
“Los estudios explicativos van más allá de la descripción de conceptos o

fenómenos o del establecimiento de relación entre conceptos; están dirigidos a responder
a las causas de los eventos, sucesos y fenómenos físicos o sociales. Como su nombre lo
indica, su interés se centra en explicar porque ocurre un fenómeno y en que condiciones
se da este, porque se relacionan dos o más variables.”(Hernández et al., 2003)
Descriptivo
• Considerando al
fenómeno
estudiado
• Miden conceptos
• Definen variables
Alcances
Investigación • Resultan de la versión

de la literatura y de la
Cuantitativa perspectiva del estudio. Correlaciones
• Depende de los objetos
• Ofrecen predicciones
del investigador para
cambiar los elementos Son • Explican la relación
en el estudio entre variables
• Cuantifican relaciones
entre variables
Explicativos
• Determinan las
causas de los
fenómenos
• Generan un sentido
de entendimiento
• Son sumamente
estructurados
Figura 1: Investigación Cuantitativa
Fuente: (Hernández et al., 2003)
Elaborado por: Integrantes del Grupo
3.2. DESARROLLO
Para el presente proyecto los estudiante recopilaran información con ayuda de
internet, libros, artículos indagando la información que contiene cada uno de los procesos
que influyen a la investigación del tema antes mencionado, los estudiantes de la
Universidad Técnica del Norte de la carrera de Ingeniería en Electrónica y Redes de
Comunicación (CIERCOM), tercer semestre de la asignatura de programación, aporta al
avance del proyecto planificado donde se procede a realizar la exploración de teoría
sustentable sobre herencia adjuntando temas para reforzar nuestros conocimientos como
se evidencia en el gráfico.
HERENCIA
CLASES DERIVADAS REGLAS
CONTROL ACCESO CONSTRUCTORES
SOBREESCRITURA SOBRECARGA
POLIMORFISMO
Figura 2: Temas de Herencia

Fuente: Integrantes del Grupo
4. RECURSOS MATERIALES Y EQUIPOS
Tabla 1: Recursos Humanos
RECURSOS HUMANOS
ESTUDIANTES DOCENTE
Royers Chávez
Axel Almeida
Darwin Carlosama Ing. Ana
Umaquinga
Pablo Ulcuango
Alder Navarrete
Autor: Integrantes del grupo
Fuente: Propia
Tabla 2: Recursos Económicos
N° RECURSOS ECONÓMICOS TOTAL

1 Copias e impresiones 2.50
2 Transporte 0.00
3 Internet 4.00
4 Costo de llamadas móviles 2.00
5 Almuerzo 12
TOTAL 20,5
Fuente: Propia
Tabla 3: Recursos de red
N° RECURSOS EN RED
1 Zotero
2 Netbeans
3 UML
4 Internet
5 Biblioteca
Fuente: Propia
5. DESCRIPCIÓN Y DESARROLLO DE LA PRÁCTICA
5.1. FUNDAMENTOS
5.1.1. HERENCIA
El concepto de clases divididas en subclases se utiliza en la vida diaria y conduce

al de herencia; la clase animal se divide en mamíferos, anfibios, insectos, aves, etcétera;
la clase vehículo se divide en autos, camiones, autobuses, motocicletas, etcétera. La clase
electrodoméstico se divide en lavadora, frigorífico, tostadora, microondas, y así
sucesivamente. La idea principal de estas divisiones reside en el hecho de que cada
subclase comparte características con la clase de la cual se deriva. Los autos, camiones,
autobuses, y motocicletas, tienen motor, ruedas y frenos; pero, además de estas
características compartidas, cada subclase tiene las propias; los autos, por ejemplo,
pueden tener maletero, cinco asientos; los camiones, cabina y caja para transportar carga,
entre otras características.(Aguilar & Martínez, 2011)
La clase principal de la que derivan las restantes se denomina base, padre o

superclase; las subclases también se denominan derivadas o hijas. Las clases reflejan que
el mundo real contiene objetos con propiedades o atributos y comportamiento; la herencia
manifiesta que dichos objetos tienden a organizarse en jerarquías; esta jerarquía, desde el
punto de vista del modelado, se denomina relación de generalización o es-un (del inglés
is-a). En programación orientada a objetos, la relación de generalización se denomina
herencia; cada clase derivada hereda las características de la cual es base y además añade
sus propias características, atributos y operaciones.(Aguilar & Martínez, 2011)
Figura 3: Herencia Simple
Fuente: (Luis Joyanes Aguilar,Ignacio Zahonero Martínez, 2011)
Las clases bases también pueden ser subclases o derivarse de otras superclases.
Así, el programador puede definir una clase animal que encapsule todas las propiedades
o atributos (altura, peso, número de patas, etc.) y el comportamiento u operaciones
(comer, dormir, andar) que pertenecen a cada uno. Los animales específicos como mono,
jirafa, canguro o pingüino tienen a su vez características propias. Como las técnicas de
herencia se representan con la citada relación es-un, se puede decir que mono es-un
Animal con características propias: subir a los árboles, saltar entre ellos, entre otras;
además, comparte con jirafa, canguro y pingüino las características propias de cualquier
animal, como comer, beber, correr, dormir, etcétera.
Otro ejemplo basado en la industria del automóvil es el siguiente: la clase caja de

cambios hace unos años tenía cuatro marchas adelante y una atrás; posteriormente se
incorporó una delantera y en los últimos años ya se comercializan automóviles con seis;
también se pueden considerar las cajas automáticas como otra extensión de clase base
figura.(Luis Joyanes Aguilar,Ignacio Zahonero Martínez, 2011)
Figura 4:Herencia de la clase animal.
5.1.2. CLASES DERIVADAS
La herencia o relación “es-un”, es la relación existente entre dos clases: una es la

derivada que se crea a partir de otra ya existente, denominada base; la nueva hereda de la
ya existente; por ejemplo: si existe una clase Figura y se desea crear una clase Triángulo,
esta última puede derivarse de la primera pues tendrá en común con ella un estado y un
comportamiento, aunque tendrá sus características propias; Triángulo “es-un” tipo de
Figura; otro ejemplo es Programador que “es-un” tipo de Empleado, como muestra en la
figura.
Figura 5: Clases Derivadas.

Como la clase base y la clase derivada tienen código y datos comunes, es evidente
que si se crea clase base; entonces la herencia en la clase derivada es una amplificación
de la base pues aquella dispone de sus atributos y métodos propios más los atributos y
métodos heredados; por ello Java utiliza la palabra reservada extends para crear clases
derivada o clases que son extensión de otra, de modo que la nueva hereda todos los
miembros datos y los métodos que pertenecen a la ya existente.
La declaración de derivación de clases debe incluir la palabra reservada extends y

a continuación el nombre de la clase base de la que se deriva; su formato en el siguiente:
Class nombre_clase extends nombre_clase_base
“En java se debe incluir la palabra reservada extends en línea de la declaración de

la clase derivada; esta palabra produce que todos los miembros no privados (private) de
la clase base se hereden en la derivada.” (Aguilar & Martínez, 2011)
Ejemplos
Declaración de las clases Programador y Triángulo; la primera se deriva o extiende a la

clase Empleado.
1. class programador extends empleado

{
public miembro público
//miembros públicos
Private miembro privado
//miembros privados
}
2. class Triangulo extends figura

{
public
//miembros públicos
protected
//miembros privados
….
}
Una vez creada la clase derivada, el siguiente paso es añadir los nuevos miembros que
se requieran para cumplir las necesidades específicas de la nueva clase.
Clase derivada.- Director
Clase base.- Empleado
Class Director extends Empleado
public nuevo método
….
private nuevo miembro
….
La declaración de la clase Director sólo tiene que especificar los nuevos

miembros, es decir, métodos y datos; todos los métodos miembros dato de Empleado no
privados son heredados automáticamente por Director; por ejemplo: el método
calcular_salario() de Empleado se aplica automáticamente a Director:
Director d;
d.calcular_salario(325000);
Ejercicios. Algoritmos y programación orientada a objetos.(Aguilar & Martínez, 2011)

5.2. CONTROL ACCESO
5.2.1. DEFINICIÓN CONTROL DE ACCESO
Según (Quintas, 2008 ) (Agustín Froufe Quintas, 2008) Java implementa cuatro
clases de especificadores de acceso, cuando se crea una nueva clase en java, se puede
especificar el nivel de acceso que se requiere para las variables de instancia y los métodos
definidos en la clase: private, protected, pulic y package.
▪ private
private String NumeroDelDocumentoIdentidad;
La clase puede contener métodos públicos, y estos métodos pueden

construir un objeto y devolverlo. pero nadie más puede hacerlo. Las variables y
métodos de instancias privadas solo pueden ser accedidos desde dentro de la clase.
No son accesibles desde las subclases de esa clase.(Agustín Froufe Quintas, 2008)
▪ protected
Protected void SoloSubClases() 
Solamente las subclases de la clase pueden crear instancias de ella. public

Cualquier otra clase puede crear instancias de la clase.
▪ public
public void CualquieraPuedeAcceder() 
Cualquier otra clase puede crear instancias de la clase.
Cualquier clase desde cualquier lugar puede acceder a las variables y métodos de
instancias públicos.
▪ Package
void MetodoDeMiPaquete() 
Nadie desde fuera del paquete puede construir una instancia de la clase.
Esto es útil si se quiere tener acceso a las clases del paquete para crear instancias
de la clase, pero sin que nadie más pueda hacerlo, con lo cual se restringe quién
puede crear instancias de la clase.
En la tabla 4 se muestra los controles de acceso.
Tabla 4: Control de accesos
Private public protected package

Para métodos y Para métodos, Si se quiere que las Usar la sentencia
variables que constantes y otras clases del mismo package para
solamente se variables paquete acceso a poder agrupar las
utilicen dentro de importantes que estas variables o clases en
la clase y que deban ser visibles métodos paquetes
deberían estar para todo el
ocultas para todo mundo.
el resto.
Fuente: (Agustín Froufe Quintas, 2008)

Elaborador por: Integrantes del Grupo
En la tabla 5 se muestra el nivel de acceso que está permitido a cada uno de los
especificadores:
Tabla 5: Nivel de accesos
Nivel de Clase Subclase Paquete Todos

Acceso
Private X
Protected X X* X
Public X X X X
Package X X
El asterisco (*) en la intersección subclase-protected quiere decir que, si una clase
es a la vez subclase y está en el mismo paquete que la clase con un miembro protected,
entonces la clase tiene acceso a ese miembro protegido. (Agustín Froufe Quintas, 2008)
Por defecto, si no se especifica el control de acceso, las varíales y métodos de

instancia se declaran package, lo que significa que, sin accesibles por todos los objetos
dentro de mismo paquete, pero no por los extremos al paquete. Una instancia de una clase,
un objeto, contiene todas las variables y métodos de instancia de la clase y de todas sus
superclases.(Agustín Froufe Quintas, 2008)
En la tabla 6 en base a categorías de visibilidad entre los elementos de clase:
Tabla 6: Visibilidad de elementos de clase
sin
Categorías visibles private modificar protected public
Misma clase SI SI SI SI
Misma subclase de paquete NO SI SI SI
Misma no-subclase de paquete NO SI SI SI
Subclase de diferente paquete NO NO SI SI
No-subclase de diferentes paquetes NO NO NO SI
5.2.2. ACCESIBILIDAD Y VISIBILIDAD EN HERENCIA
En una clase existen secciones públicas, privadas y protegidas. Los elementos

públicos son accesibles a todas las funciones; los elementos privados son accesibles sólo
a los miembros de la clase en que están definidos y los elementos protegidos pueden ser
accedidos por clases derivadas debido a la propiedad de la herencia. En correspondencia
con lo anterior, existen tres tipos de herencia: pública, privada y protegida. Normalmente
el tipo de herencia más utilizada es la herencia pública. (Joyanes Aguilar et al., 2010)
Con independencia del tipo de herencia, una clase derivada no puede acceder a
variables y funciones privadas de su clase base. Para ocultar los detalles de la clase base
y de la clases y funciones externas a las jerarquías de clases, una clase base utiliza
normalmente elementos protegidos en lugar de elementos privados. Suponiendo herencia
pública, los elementos protegidos son accesibles a las funciones miembro de todas las
clases derivadas.
En la tabla 7 se visualizará la independencia del tipo de herencia
Tabla 7: Acceso a variables y funciones según tipo de herencia
Acceso a variables y funciones según tipo de herencia

Tipo de herencia Tipo de elemento ¿Accesible a clase
derivada?
Pública Pública Si
Protegida Si
Privada No
Privada Pública Si
Protegida Si
Privada No
Fuente: (Joyanes Aguilar et al., 2010)

HERENCIA PUBLICA
NORMA Es una clase derivada y tiene acceso a los elementos
La herencia es privada, si en caso de no utilizar la palabra publico y protegidos de su clase base, los elemntos
pública, los elementos de la clase base serán inaccesibles. públicos se heredan como elementos públicos; los
elementos protegidos permanecen protegidos.
ACCESIBILIDAD Y
VISIVILIDAD EN HERENCIA
HERENCIA PROTEGIDA HERENCIA PRIVADA

Los miembros publicos y protegidos de la clase base se Una clase derivada hereda los miembros publicos y
convierten en miembros protegidos de la clase derivada protegidos de la clase base de forma privada; L a
y los miembros privados de la clase base son herencia privada se utiliza con menos frecuencia .
inaccesibles
Figura 6:Accesibilidad y Visibilidad en Herencia

Elaborador por: Integrantes del Grupo
En la tabla 8 resume los efectos de los tres tipos de herencia en la accesibilidad de los
miembros de la clase derivada.
Tabla 8: Tipos de herencia y accesos que permiten
TIPOS DE HERENCIA Y ACCESOS QUE PERMITEN

Tipo de herencia Acceso a Acceso a
miembro clase miembro a
base clase derivada
Pública Pública
pública Protegida Protegida
Privada Inaccesible
Pública Protegida
protegida Protegida Protegida
Privada Inaccesible
Pública Privada
privada Protegida Privada
Privada Inaccesible
5.3. SOBREESCRITURA, CONSTRUCTORES Y POLIMORFISMO
5.3.1. SOBREESCRITURA
Según (Moreno Pérez, 2014) una de las propiedades fundamentales de los lenguajes
Orientados a Objetos es la sobreescritura u overrigding de métodos. Los métodos son los
únicos que se pueden sobrescribir; con los elementos miembro esta técnica no es posible.
La sobreescritura permite modificar el comportamiento de la clase padre (también

llamada clase principal o superclase).
Para que dicho método con diferente funcionalidad sea sobrescrito, deberá cumplir los
siguientes preceptos:
▪ Tiene que tener el mismo nombre.

▪ El retorno de la clase padre e hijo deberá ser del mismo tipo.
▪ Deberá de conservar la misma lista de argumentos que el mismo método en la
clase padre.
Un ejemplo de sobrecarga de métodos sería el siguiente:
packade sobreescribe;
public class Pajaro {
protected String nombre;
protected String color;
public String getDetalles ( ){
return “Nombre:” + nombre + “\n” + “Color: ” + color;
}
}
package sobreescribe;
public class Loro extend Pajaro {
protected String pedigrí;
public String getDetalles ( ) {
return “Nombre:” + nombre + “\n” + “Color: ” + color + “\n” + “Pedigri: ” +
pedigrí;
}
}
Según el autor (Moreno Pérez, 2014), del ejemplo anterior se puede observar los
siguiente:
▪ La clase Loro desciende de la clase Pájaro.

▪ La clase Loro sobrescribe el método getDetalles( ), ambas con el mismo nombre.
▪ El método getDetalles( ) de la clase padre e hija tiene la misma lista de
argumentos.
▪ El método getDetalles( ) de la clase padre e hija devuleven un objeto String
(mismo tipo).
▪ El método getDetalles( ) de la clase padre e hija tienen el mismo modificador de
acceso (publico).
5.3.2. SOBRECARGA DE MÉTODOS (OVERRIDING)
“La sobrecarga es la implementación varias veces del mismo método con ligeras
diferencias adaptadas a las distintas necesidades de dicho método”. (Moreno Pérez, 2014)
Como ha mencionado (Moreno Pérez, 2014) antes, la sobrecarga implica una

implementación repetida del mismo método. Para crear métodos sobrecargados se debe
crear métodos con el mismo nombre, pero con distinta lista de parámetros. A
continuación, se enumeran las reglas para sobrecargar un método.
▪ Los métodos sobrecargados deben cambiar la lista de argumentos

obligatoriamente.
▪ Un método puede estar sobrecargado en la clase o en una subclase.
▪ Al sobrecargar un método se pueden utilizar las mismas excepciones o añadir
algunas.
▪ Los métodos sobrecargados pueden cambiar el tipo de retorno o el modificador
de acceso.
(Moreno Pérez, 2014) cita como ejemplo una clase persona, en la cual se va a almacenar
datos de ciertas personas como: nombre, teléfono, dirección, entre otros. El problema será
que se requiere almacenar para su posterior tratamiento el primer y segundo apellido de
todos los individuos. Ahora, si por ejemplo se tiene un inglés o italiano de los que por
costumbre no se utiliza su segundo apellido. Esta es una buena ocasión de utilizar un
método sobrecargado. Un ejemplo de esto sería lo siguiente:
public class persona {

private int sinsegundo=0;
private String nombre;
private String apellido1;
private String apellido2;
public void setNombre (String nom, String ape1, String ape2) {
nombre = nom;
apellido1 = ape1;
apellido2 = ape2;
}
public void setNombre (String nom, String ape1, String ape2) {
nombre = nom;
apellido1 = ape1;
sinsegundo = 1;
}
}
“Como se puede observar el código anterior cumple con todas las reglas enumeradas
anteriormente. Hay que recordar que los métodos sobrecargados deben de cambiar la lista
de argumentos del método.” (Moreno Pérez, 2014)
5.3.3. REGLAS PARA LA SOBREESCRITURA
Para identificar un método sobrescrito se pone la notación @override, esto es

común encontrar cuando el trabajo es con clases abstractas o interfaces, donde se obliga
a implementar los métodos de este si son heredadas o implementadas respectivamente.
Esta notación no siempre está presente, pero es recomendable escribirla pues de esta
manera el compilador reconoce que se están sobrescribiendo los métodos ayudando a
que, si hay alguna equivocación al crear un método distinto, el compilador dará un aviso,
también es útil cuando el trabajo es con código de otras personas. (Henao, 2014).
(Henao, 2014) presenta un ejemplo donde se sobreescribe el método tocar ()
public class Instrumento{

public String tipo;
public void tocar()
{
System.out.println("Tocar un Instrumento");
}
}
class Guitarra extends Instrumento {
@Override
public void tocar() {
System.out.println("Tocar La Guitarra");
}
}
(Henao, 2014) expone la explicación del ejemplo. La clase Guitarra hereda de la

clase Instrumento, esta última tiene el método tocar () con una implementación diferente
a la del método en la clase Guitarra (el mensaje es distinto), al tener la
anotación @Override, da a entender que se está sobreescribiendo dicho método y se le
puede dar la lógica específica para la clase Guitarra.
5.4.CONSTRUCTORES
5.4.1. DEFINICIÓN CONSTRUCTOR
El objetivo de un constructor es el de inicializar un objeto cuando éste es creado.

Se asigna los valores iniciales, así como los procesos que esta clase deba realizar.
Se utiliza para crear tablas de métodos virtuales y poder así desarrollar el polimorfismo,
una de las herramientas POO. Al utilizar un constructor, el compilador determina cuál de
los objetos va a responder al mensaje (virtual) que se ha creado. Tiene un tipo de acceso,
un nombre y un paréntesis. (Latorre, 2010).
El autor (Latorre, 2010) menciona que en java es un método especial dentro de

una clase, que se llama automáticamente cada vez que se crea un objeto de esa clase.
Posee el mismo nombre de la clase a la cual pertenece y no puede regresar ningún valor
(ni siquiera se puede especificar la palabra reservada void). Por ejemplo, si se añade a la
clase Suma un constructor, se debe llamar también Suma. Cuando en una clase no se
escribe propiamente un constructor, java asume uno por defecto (que el Constructor es
vacío, es decir sin parámetros).
5.4.2. CONSTRUCTOR POR DEFECTO
Según el autor (Moreno Pérez, 2014), un constructor por defecto es un constructor

sin parámetros que no hace nada. Cuando no se especifica en el código. Se ejecuta siempre
de manera automática e inicializa el objeto con los valores especificados o
predeterminados por el sistema (los atributos numéricos a ceros, los alfanuméricos a
nulos, y las referencias a objetos a null).
5.4.3. CONSTRUCTOR CON PARÁMETROS
“Puede ser más de uno y tiene el mismo nombre de la clase. Nunca devuelve un
valor y no puede ser declarado como static, final, native, abstract, synchronized. Por lo
general se declara los constructores como públicos (public) para que puedan ser usados
por cualquier otra clase.” (Moreno Pérez 2014).
EJEMPLO
(Ceballos Sierra, 2010). Cita un ejemplo en el cual, aplicando la teoría expuesta, se va

añadir a la clase CCuentaAhorro un constructor con parámetros, la cantidad de parámetros
será igual a los atributos heredados y propios que tenga la clase. En este caso un objeto
CCuentaAhorro contendrá los atributos: nombre, cuenta, saldo, tipoDeInteres y
cuotaMantenimiento. Basados en esto, el constructor podría ser así:
public CCuentaAhorro (String nom, String cue, double sal,

double tipo, double mant)
{
super (nom, cue, sal, tipo); // invoca al constructor CCuenta
asignarCuotaManten(mant); // inicia cuotaMantenimiento
}
La primera línea del constructor anterior llama al constructor de CCuenta,

superclase de CCuentaAhorro. Lógicamente, la clase CCuenta debe tener un constructor
con cuatro parámetros del tipo de los argumentos especificados. La segunda línea invoca
al método asignarCuotaManten para iniciar el atributo cuotaMantenimiento de
CCuentaAhorro
De acuerdo con los constructores definidos en la clase CCuentaAhorro, son declaraciones

válidas las siguientes:
public class Test

{
public static void manin(String [ ] args )
{
CCuentaAhorro cuenta01 = new CCuentaAhorro ( );
CCuentaAhorro cuenta02 = new CCuentaAhorro ( “cliente 02”,
“11111”, 10000, 2.5, 1);
//…..
}
}
(Ceballos Sierra, 2010). Explica que, en este ejemplo, la sentencia primera

requiere CCuentaAhorro un constrcutor sin parámetros y en CCuenta otro. En cambio, la
segunda sentencia requiere en CCuentaAhorro un constructor con parámetros y en
CCuenta otro que se pueda invocar como se indica a continuación, con el fin de iniciar
los atributos definidos en la superclase, con los valeres pasados como argumentos.
Super (nombre, cuenta, saldo, tipoInteres);
Según lo expuesto, cuando se crea cuenta01 y cuenta02, primero se construye la

porción del objeto correspondiente a su superclase y, a continuación, la porción del objeto
correspondiente a su subclase. Esto es una forma lógica de operar, ya que permite al
constructor de la subclase hacer referencia, cuando sea preciso, a los atributos de su
superclase que ya han sido iniciados. (Ceballos Sierra, 2010).
5.5. SOBRECARGA
“En la sobrecarga se define múltiples constructores para una clase cuando el objeto
pueda ser inicializado de múltiples formas. Al sobrecargar un constructor se variaría el
tipo y número de parámetros que se recibe.” (Moreno Pérez 2014)
La siguiente clase muestra un ejemplo de sobrecarga de constructores.
1 public class rectangulo

2{
3 private int ancho;
4 private int alto;
5 rectangulo (in tan, int al){
6 this.ancho = an;
7 this.alto = al;
8 }
9 rectangulo() {
10 ancho=alto=0;
11 }
12 rectangulo (int dato) {
13 ancho=dato=alto;
14 }
15 }
(Moreno Pérez 2014) argumenta que cuando existe más de un constructor para
una clase se dice que esta sobrecargado. Cuando se crea un objeto con new, Java elige el
constructor más adecuado dependiendo de los parámetros utilizados.
5.6. DESTRUCTOR
Un destructor en algunos lenguajes de POO es un método de una clase que se

llama justo antes de una instancia de esa clase y se elimina de la memoria. No todos los
lenguajes de programación orientados a objetos suelen tener un destructor. La
contrapartida de un destructor es un constructor que se ejecuta cuando se crea el objeto,
se instancia y se lo inicializa. (Latorre, 2010)
NOTA: (Latorre, 2010) menciona que si se crea un programa y no se define el

Constructor, el sistema toma por defecto al Constructor Vacío, pero si se define a un
Constructor con parámetros y al Vacío, esto se llama Sobrecarga de Constructores, y es
cuando un programa tienes 2 o más Constructores, de los cuales solo uno puede estar
vacío (es decir sin Parámetros).
Uno de los lenguajes donde no existen destructores es Java, esto es gracias al

sistema de liberación llamado garbaje collector (recolector de basura). El recolector de
basura recolecta todas las variables u objetos que no se estén utilizando y que no haya
ninguna referencia a ellos por una clase en ejecución, liberando así automáticamente la
memoria de la computadora. Sin embargo también se le puede hacer un llamado usando
la palabra System.gc(); pero esta no es la única razón para que se active el recolector
de basura (se activara cuando él lo decida, generalmente cuando falta memoria).
(Moreno Pérez 2014).
5.7. POLIMORFISMO
El polimorfismo, en POO, se refiere a la posibilidad de acceder a un variado rango

de distintas funciones a través de la misma interfaz. Es decir, un mismo identificador
puede tener distintas formas (diferentes cuerpos de función, múltiples comportamientos)
dependiendo del contexto en el que se halle. Es muy parecido o más bien tiene sus bases
en la capacidad de herencia que presentan los lenguajes orientados a objetos. Con la
herencia las clases padres comparten métodos con las clases hijas, el polimorfismo hace
prácticamente lo mismo, pero en vez de clases padres se tiene clases abstractas.
(«POLIMORFISMO EN JAVA - Conceptos de JAVA» 2017)
“Las clases abstractas tienen métodos abstractos, es decir, métodos que solo están
declarados sus nombres, pero su forma de actuar difiere de una clase hija a otra.”
(«POLIMORFISMO EN JAVA - Conceptos de JAVA» 2017)
EJEMPLO DE POLIMORFISMO EN JAVA
Figura 7: Polimorfismo en java

Fuente: Conceptos de JAVA
Para este ejemplo se utiliza una Interface, una clase Abstracta y 2 clases Concretas como
se observa en el siguiente diagrama:
Figura 8: Interface, de una clase abstracta y 2 clases
Fuente: Conceptos de JAVA
Se observa que se tiene un árbol de herencia definido, donde la clase Abstracta

Animal implementa la interface IAnimal y al mismo tiempo es clase Padre de Gato y
Perro, los cuales implementaran no solo los métodos abstractos de Animal sino también
el método comunicarse() de la interface IAnimal. (Henao, 2013)
Una de las reglas al trabajar con clases abstractas o interfaces es: todas las clases
concretas que desciendan de ellas están obligadas a implementar sus métodos, en este
caso la clase Animal al ser abstracta no está obligada a hacerlo, pero sus hijas sí. (Henao,
2013)
5. RESULTADOS Y CONCLUSIONES
- Se logró definir varios temas los cuales se encuentra directamente ligados a la

guía, la cual se desarrolló de la mejor manera basándose directamente en la
metodología descrita.
- Se obtuvo información comprensible, que permite mayor perceptibilidad para el
lector e investigador.
- Las estrategias metodológicas delimitadas se establecieron de acuerdo con los
criterios básicos de compresión para cada uno de los temas desarrollados en la
guía.
- La guía realizada ayuda a la fácil comprensión del tema herencia, también
proporciona ejemplos detallados, los cuales brindan una idea clara de los usos y
aplicaciones de herencia.
6. PRÁCTICA LABORATORIO
Herencia en Consola
Clase Padre
Figura 9: Código de la Clase Padre(Persona)

Figura 10: Ejecución en la Consola de Persona
Figura 11: Ejecución en Consola de Estudiante

Figura 12: Ejecución en Consola de Docente
Figura 13:Ejecución en Consola-Salida

Herencia en Interfaz Grafica
Tienda de Discos CIERCOM
Figura 14: Autores

Figura 15: Ventana Principal

Figura 16: Opción Nuevo
Figura 17: Opción Cliente (Ingresar datos del cliente1)

Figura 18: Opción Cliente (Ingresar datos del cliente1)
Figura 19: Grabado correctamente

Figura 20: Opción Empleado
Figura 21: Ingresar los datos del empleado (vendedor1)

Figura 22: Ingresar los datos del empleado (vendedor2)
Figura 23: Ingresar los datos del empleado (cajero1)

Figura 24: Ingresar los datos del empleado (cajero2)

Figura 26: Opción Discos (Ingresar información del disco)


Figura 31: Opción Factura

Figura 32: Ingresar información para generar factura
Figura 33: Ingresar la cantidad de discos a comprar

Figura 34: Compra agregada a la factura
Figura 35: Ingresar la cantidad de nuevos discos a comprar

Figura 36: Compra agregada a la factura

Figura 38: Opción Ventas (Revisar Ventas)
Figura 39: Seleccionar el número de factura (Ver factura)

Figura 40: Opción Salir
CONSTRUCTORES
Figura 41:Crear los constructores

Figura 42: Asignar parámetros a los constructores
Figura 43: Imprimir parámetros de los constructores

SOBREESCRITURA
Figura 44: Creación del proyecto ,paquetes y clases

Figura 45: Asignar parámetros a los constructores
Figura 46: Métodos @override

Figura 47: Código para comparar Strings
Figura 48: Código del botón(Interfaz grafica)

Figura 49: jframe
Figura 48: Ejecución del programa

7.BIBLIOGRAFÍA
Aguilar, L. J., & Martínez, I. Z. (2011). Programación en java6. Algoritmos,
programación orientada a objetos e interfaz gráfica de usuario (Primera
edición). México, D. F: The McGraw-Hill.
Agustín Froufe Quintas. (2008). Java 2 Manual de usuario y tutorial (Quinta). México:
Alfaomega Grupo Editor.
Ceballos Sierra, F. J. (2010). Java 2: curso de programación (4a. ed.). RA-MA
Editorial.
Henao, C. (2013, junio 1). CoDejaVu: Ejemplo de Polimorfismo En Java. Recuperado
27 de junio de 2017, a partir de http://codejavu.blogspot.com/2013/06/ejemplo-
de-polimorfismo-en-java.html
Henao, C. (2014, mayo 12). CoDejaVu: Sobreescritura y SobreCarga de Métodos en
Java ( Overriding y Overloading ). Recuperado 27 de junio de 2017, a partir de
http://codejavu.blogspot.com/2014/05/sobreescritura-y-sobrecarga-de-
metodos.html
Hernández, R., Collado, C. F., & Lucio, P. B. (2003). Metodología de la Investigación
(Tercera Edición). (Tercera edición). México: McGraw-Hill.
Joyanes Aguilar, Luis Zahonero, & Ignacio Martínez. (2010). Programación en C,
C++, JAVA y UML. México: McGraw-Hill.
Latorre, G. (2010, marzo 22). Constructor y Destructor. Recuperado 27 de junio de
2017, a partir de http://gl-epn-programacion-
ii.blogspot.com/2010/03/constructor-y-destructor.html
Luis Joyanes Aguilar,Ignacio Zahonero Martínez. (2011). Programación en java6.
Algoritmos, programación orientada a objetos e interfaz gráfica de usuario
(Primera edición). C.P. 01376, México, D. F: The McGraw-Hill. Recuperado a

partir de http://www.armandovalera.info/wp-
content/uploads/2014/11/Programaci%C3%B3n-en-java-6-Luis-Joyanes-
Aguilar-FREELIBROS.ORG_.pdf
Moreno Pérez, J. C. (2014). Programación. RA-MA Editorial.
POLIFORMISMO EN JAVA - Conceptos de JAVA. (s. f.). Recuperado 27 de junio de
2017, a partir de
https://sites.google.com/site/conceptosdejava/home/poliformismo-en-java
Editorial.
metodos.html

2017, a partir de
Editorial.

metodos.html
2017, a partir de

Informe Herencia

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Informe Herencia

Transféré par

Droits d'auteur :

Formats disponibles

ÍNDICE

Tabla 1: Recursos Humanos ............................................................................................. 9

Figura 1: Investigación Cuantitativa................................................................................. 7

La herencia crear jerarquías de clases relacionadas y reduce la cantidad de código

Para la recolección de información se utilizó técnicas de investigación,

Con el desarrollo de esta guía, se impartirá la información y conocimientos

2.1. OBJETIVO GENERAL

Elaborar una guía práctica con estrategias metodológicas basadas en Herencia.

2.2. OBJETIVOS ESPECÍFICOS

• Definir los temas que se van a desarrollar en la guía.

• Delimitar estrategias metodológicas para la fácil comprensión tema.

3.1.1. ESTUDIOS DESCRIPTIVOS

Busca especificar propiedad, características y rasgos importantes de cualquier

Los estudios descriptivos pretenden medir o recoger información de manera

“Los descriptivos se centran en recolectar datos que muestran en un evento,

3.1.2. ESTUDIO CORRELACIONAL

“Los estudios explicativos van más allá de la descripción de conceptos o

Investigación • Resultan de la versión

Para el presente proyecto los estudiante recopilaran información con ayuda de

que influyen a la investigación del tema antes mencionado, los estudiantes de la

Universidad Técnica del Norte de la carrera de Ingeniería en Electrónica y Redes de

Comunicación (CIERCOM), tercer semestre de la asignatura de programación, aporta al

avance del proyecto planificado donde se procede a realizar la exploración de teoría

CLASES DERIVADAS REGLAS

CONTROL ACCESO CONSTRUCTORES

Figura 2: Temas de Herencia

Tabla 1: Recursos Humanos

Tabla 2: Recursos Económicos

N° RECURSOS ECONÓMICOS TOTAL

Tabla 3: Recursos de red

El concepto de clases divididas en subclases se utiliza en la vida diaria y conduce

La clase principal de la que derivan las restantes se denomina base, padre o

Otro ejemplo basado en la industria del automóvil es el siguiente: la clase caja de

5.1.2. CLASES DERIVADAS

La herencia o relación “es-un”, es la relación existente entre dos clases: una es la

Figura 5: Clases Derivadas.

La declaración de derivación de clases debe incluir la palabra reservada extends y

Class nombre_clase extends nombre_clase_base

“En java se debe incluir la palabra reservada extends en línea de la declaración de

Declaración de las clases Programador y Triángulo; la primera se deriva o extiende a la

1. class programador extends empleado

2. class Triangulo extends figura

Clase derivada.- Director

Clase base.- Empleado

Class Director extends Empleado

public nuevo método

private nuevo miembro

La declaración de la clase Director sólo tiene que especificar los nuevos

Ejercicios. Algoritmos y programación orientada a objetos.(Aguilar & Martínez, 2011)

5.2.1. DEFINICIÓN CONTROL DE ACCESO

private String NumeroDelDocumentoIdentidad;

La clase puede contener métodos públicos, y estos métodos pueden

Protected void SoloSubClases() 

Solamente las subclases de la clase pueden crear instancias de ella. public

public void CualquieraPuedeAcceder() 

Cualquier otra clase puede crear instancias de la clase.

En la tabla 4 se muestra los controles de acceso.

Tabla 4: Control de accesos

Private public protected package

Fuente: (Agustín Froufe Quintas, 2008)

Tabla 5: Nivel de accesos

Nivel de Clase Subclase Paquete Todos

Por defecto, si no se especifica el control de acceso, las varíales y métodos de