Documente Academic
Documente Profesional
Documente Cultură
Este documento está escrito para ayudar a quien lo necesite. Puedes hacer con él lo que quieras,
pero siempre de forma gratuita y desinteresada. Además, es demasiado malo como para venderlo. Se
reirían de ti :)
Si quieres aportar algo a este documento, no dudes en ponerte en contacto con el Grupo de
Usuarios de Linux de la Universidad Carlos III de Madrid (gul@gul.uc3m.es).
Contenido
Aquí tienes la lista de contenidos del texto. Los apartados marcados con * son sólo orientativos y no están
ampliamente explicados aquí, ya que no forman parte del objetivo de este texto. Puedes encontrar una
explicación exhaustiva de estos apartados en cualquier libro de Java, además de las explicaciones que te
dará el profesor de la asignatura. Bueno, en algunas ocasiones, que debería dar.
Introducción. Cultureta.
pelín de historia
Platón y la OOP
el problema...
... y la solución
concepto de objeto
propiedades
métodos
concepto de clase
Java
¿por qué Java?
caracteríaticas generales de Java *
facilidad (je je jeeee)
lenguaje interpretado
tamaño de los programas
orientado a Internet
JVM
Cómo usar el compilador y la JVM (javac, java)
Recursividad
definición
metodología: la cola del cine
partes de un método recursivo
los factoriales
Herencia
para qué sirve
cómo se usa: extends
redefinición de métodos
uso de super()
una nota bastante importante
Casting
preludio al casting: las referencias
la señora referencia
cómo funciona
comparación de referencias
Arreglando bicicletas: parámetros que son referencias
casting
¿Por qué?
cómo se usa
resumen
comerte el coco 6
upcasting, downcasting, Y siguiendo con el inglés, explicit and implicit cast
upcasting
downcasting
casting implícito
casting explícito
La Clase Object
definición
contenido *
¿para qué ese contenido?
la gran utilidad de la clase Object: referencias de tipo Object
Interfaces
definición
uso básico de interfaces
uso avanzado de interfaces: referencias de tipo de interfaces
¿herencia?¿Interfaces?¿comorl?
Epílogo
Por tanto, es necesario que te conciencies de que leer este texto no implica
aprobar: implica ser capaz de aprobar. Si te sirve de algo, cuando yo llegué a primero,
sabía bastante menos de lo que hay aquí escrito.
Prefacio
No te engañes: tenemos mucha labor por delante. Pero no hay que pensar que es
ardua y temible. En absoluto. O al menos, espero que no lo sea para ti.
Primero, hay que comerse el coco bastante, pero no para alcanzar complejos
conceptos (bueno, para esto también), sino para todo lo contrario: para conseguir poner
nuestro pensamiento a la altura de un cacho de silicio, que no parece muy listo....
He intentado explicar todo este rollo usando ejemplos de la vida real. Tal vez
quede “un poco” asquerosamente pedante explicar las clases metiendo a Platón por
medio, pero creo que haciéndolo vamos a entender los conceptos más fácilmente, y
sobre todo, no se van a olvidar. Por supuesto, no creas que todo es Platón, también
hablaremos de tu vecina, de la mesa Margarita, de “páginas gué”, la bicicleta Anacleta,
y de mil cosas más. Bueno, mil... lo que se dice mil....
Por supuesto, todo ello respaldado por el pez Otilio, el pato Onorato y el pájaro
que no sé cómo demonios se llama, que no son más que excusas para apartar un poco la
atención y hacer la lectura un pelín más agradable.
Espero haber logrado, aunque sólo sea en pequeña parte, estos objetivos. Ahora,
como dice la historia de la sopa de piedra, debes poner tú de tu parte. ¡Ánimo!
Introducción. Cultureta.
Normalmente, para empezar se opta por definir qué es programar, cómo se lleva
a cabo, conceptos como “software”, “hardware”,
“memoria”, etc etc etc. Vamos a ignorar todo
este rollo porque realmente no importa
en absoluto. Nosotros, por ahora, no
nos vamos a preocupar de la Yo soy un programador
capacidad de la memoria o de la leche.
de la velocidad del proce-
sador. A nosotros nos inte-
resa programar.
Cuando aprendemos
a programar siempre se nos
plantea si debemos
compaginar la progra-
mación con el lenguaje de programación. Parece una tontería,
pero podemos aprender OOP sin saber ningún lenguaje. Es cierto: podemos
saber sobre clases, objetos, herencia, casting, etc sin saber una maldita palabra de
ningún lenguaje. Sin embargo, siempre es positivo compaginar nuestro aprendizaje de
programación con el de un lenguaje propicio para ello.
¿Ves? El programa empieza en un punto, y acaba en otro. Esto, claro, tiene sus
inconvenientes: no podemos hacer repeticiones, ni nada de eso. Nacieron las “sentencias
condicionales”:
procedure debuti;
begin
Writeln('me alegro');
end;
procedure notandebuti;
begin
Writeln('alegrate!');
end;
begin
Writeln('¿Cómo estás?');
readln(cad);
if (cad='bien') then debuti else notandebuti;
end.
Hay muchos más tipos de programación, y también muchos otros lenguajes muy
raros, Smalltalk, ADA, Prolog.... En realidad, hoy en día muchos de estos lenguajes se
usan con fines didácticos o experimentales.
Platón y la OOP
a) Datos
b) Métodos
Supongamos dos objetos semejantes, por ejemplo, dos mesas. Datos que pueden
concernir a las mesas, por ejemplo, son su color, número de patas, su forma, etc. Así, si
tenemos dos “objetos mesa”, cada uno con datos diferentes, tenemos dos mesas
diferentes, que es lo que planteábamos al principio: dos objetos de la misma naturaleza
(“mesa”), pero diferentes entre sí. ¡A Platón esto le habría encantado!
Debido a que los datos de un objeto definen en parte este objeto (lo diferencian de
los demás), a veces llamamos a estos datos “Propiedades”.
¿Se te ocurre algún método propio de una mesa? A mí no, las mesas son objetos
puramente pasivos, ellas mismas no hacen nada. Sin embargo, vamos a suponer que el
cambio de color es una acción propia de la mesa (y no del pintor).
¿Cómo un carpintero puede crear una mesa? Según este griego, su alma, antes de
nacer, vislumbró las Ideas, y durante la vida de la persona, el alma recuerda algunas de
estas Ideas (aunque no todas....) Así, un carpintero recuerda haber visto la “Idea de
Mesa”, y por ello sabe hacer mesas. Es decir, el carpintero se FIJA en la “Idea de Mesa”
para crear una mesa.
OBJETO
CLASE
PROPIEDADES
MÉTODOS
INSTANCIA
¡Cuidado!
Si decimos que dos objetos de la misma clase tienen las mismas propiedades, tal
vez lo que realmente queramos decir es que dos objetos de la misma clase tienen
EL MISMO VALOR PARA TODAS Y CADA UNA.DE SUS PROPIEDADES.
Es evidente que dos objetos de la misma clase van a tener las mismas
propiedades: dos mesas tendrán color, forma, número de patas, etc. Pero tal vez
digamos que dos mesas tienen las mismas propiedades cuando queremos decir
que ambas mesas tienen la misma forma, el mismo color y el mismo número de
patas. Hay que tener cuidado con esto, aunque tampoco es tan importante.
Java
Java nació con una intención muy clara: hacer la vida más fácil al programador.
C++ es el lenguaje más potente que existe ahora mismo. Pero tiene un grave problema:
es lo más complicado que hay. Un ejemplo:
#include <owl.h>
: TApplication(AName,
hInstance,
hPrevInstance,
lpCmdLine,
nCmdShow) {};
virtual void InitMainWindow();
};
// el MainWindow de la clase
void THelloApp::InitMainWindow()
{
MainWindow = new TWindow(NULL, "Hola Mundo");
}
Bueno, pues este fragmento de código abre una ventana con el título “Hola
Mundo!”.
Visto lo visto, Java trata de hacer la vida un poco más fácil. Además, un
programa en Java ocupa bastante poco espacio en disco, mientras que uno en C++ ocupa
todo lo que quieras y un poco más. Así que, gracias a eso, Java es también propicio para
aplicaciones que corran por Internet y esas cosas. Pero todo eso ya lo veremos.
Antes de seguir adelante, vamos a pararnos un poco para recapacitar sobre si has
entendido los conceptos de:
Vamos a escribir un pequeño programa en Java. ¿Su fin? definir las mesas que
tanto tiempo nos han acompañado. Recordemos la CLASE MESA:
Definición de propiedades
class Mesa {
String color;
int numPatas;
String forma;
.
.
.
Esto ya tenemos que ser capaces de entenderlo bien. Una mesa tiene un color, un
número de patas y una forma. El número de patas es un número entero, mientras que la
forma y el color son cadenas de caracteres. Bueno, pues así se han definido. Ahora no
ha lugar a pensar cómo se define el color de una mesa determinada, o su forma, o cómo
saber qué color tiene otra mesa cualquiera..... todo eso ya lo veremos. Ahora estamos
DEFINIENDO la clase Mesa, no hacemos nada más.
Definición de métodos
a) valor de retorno.
b) parámetros
Un método que calcule 5*4 está claro que no va a necesitar parámetros, porque el
método no puede hacer nada más que calcular 5*4. Sin embargo, un método que calcule
la multiplicación de dos enteros cualquiera necesitará conocer esos enteros, es decir, se
los daremos como parámetro. Es como si queremos saber dónde está determinada calle,
y le preguntamos a alguien: tenemos que decirle qué calle buscamos. Imagínate,
“Disculpe, ¿podría decirme dónde está la calle?” No tiene sentido, habría que preguntar
“Disculpe (educación ante todo), ¿podría decirme dónde está la calle Butarque?”.
Bueno, pues como éste se te pueden ocurrir mil ejemplos
Es
MUY IMPORTANTE
que diferencies cuándo
un método necesita
parámetros y cuándo no.
Una cosa sí es cierta: no hay una regla general para saber si un método necesita
parámetros, para saberlo necesitamos la mplementación del código, y el sentido común.
float raizCuadrada(int a)
recibe un entero y devuelve un real
Debe quedar MUY MUY MUY claro este rollo de los parámetros y del tipo de
dato devuelto por un método. Vamos a ver los métodos anteriores implementados y
comentados para que se vea todo mucho mejor, y ya de paso aprendemos cómo hace un
método para devolver un valor usando “return”:
Este método recibe dos enteros, a y b, y devuelve su suma, que será otro entero.
Si hacemos en cualquier parte del programa
Recibe dos cadenas y las concatena poniendo un espacio en blanco entre medias.
Fíjate en la diferencia entre usar “+” con números y usarlo con cadenas. Si en cualquier
punto del programa escribimos
void saludo(){
System.out.println(“Holas!”);
}
saludo();
Un método puede devolver un valor, o bien puede no devolver nada. Depende de cómo
hemos definido el método: si lo definimos como “void”:
void saludo()
int suma(....)
Este método es casi igual al que hemos visto poco más arriba, peeeeeeeeeero tiene un
grave problema: hemos dicho que devuelve un entero ( INT suma(int a, int b) ), pero no
hay ningún “return” en el cuerpo del método. Habrá un error de compilación!
La única pega es que la segunda línea llama al método “suma”, le pasa sus
parámetros pertinentes, pero nadie recibe el resultado. Esto, parece una chorrada, pero
es útil. Supongamos que tenemos un método:
abrirFichero(“miFichero.txt”);
Bueno, ¡pues esto es todo sobre los métodos! Antes de seguir adelante, como
siempre, asegúrate de haber entendido bien los conceptos de:
PROPIEDAD
MÉTODO
TIPO DE DATOS (int, float....)
PARÁMETROS
VALOR DE RETORNO DE UN MÉTODO
SENTENCIA RETURN
VOID
Recuerda siempre que un valor de retorno puede ser ignorado
Ejercicio
Una vez hayas entendido perfectamente todo este rollo, puedes escribir la
definición completa de la clase Mesa. Plantéate qué parámetros le pasaríamos al método
cambiarColor() y qué valor devolvería. ¡Vamos!
Solución
Ya tenemos definida la clase Mesa. Ahora quiero crear una mesa. ¿Cómo se hace
eso?...
Cuando creemos un objeto, la JVM genera una “burbujita” que es nuestro objeto.
Claro, que para que ese objeto haga cosas necesitamos “llamarlo” de alguna forma. Si
quieres que, en medio de una fiesta atestada de gente tu amigo Miguel te diga, por
ejemplo, la hora, como digas “¡Dime la hora!”, no te van a hacer ni caso, porque cada
uno pensará (si te ha oído) que no le estás llamando a él. Tendrás que decir “¡Miguel,
dime la hora!”, para que el señor Miguel te haga caso. En definitiva, que si vas dando
gritos por la calle ni Dios te va a hacer caso, mientras que si a cada frase le antepones el
nombre de la persona a la que imperas, pues ya te puede atender.
En Java esto es exactamente igual, a cada objeto se le debe dar un nombre para
poder “llamarle” de alguna forma cuando le necesites. Bien, pues a estos nombres se les
denomina Referencias. Si yo creo dos mesas y quiero cambiar el color de una sóla,
¿Cómo le digo a la JVM a qué mesa quiero cambiar el color? Pues fácil, si creo dos
mesas, a una la llamo “Margarita” y a la otra “Alberto”, y luego digo que cambie el
color de Margarita.
“new“significa “nuevo”. Y este es un ejemplo de otra cosa que por este simple
hecho no va a recibir ningún premio. “new” sirve para
por ejemplo:
Supongamos que quiero crear dos mesas, Margarita y Alberto, y quiero cambiar
el color de la mesa Margarita. Tendré que llamar al método cambiarColor() de la mesa
Margarita. ¿Cómo se hace esto? Pues usando algo tan tonto y tan simple como un punto:
Alberto.cambiarColor(“Azul”);
Ya está. Hala. ¿Parecía complicado todo esto? Pues ya ves qué complicación
más grande. Ya sabemos definir objetos, crearlos y usar sus métodos. Para que te
convenzas, aquí tienes un cachito de mi práctica de Junio:
log.write(" tipoReserva = "+r.getTipoReserva());
log.write(" horaInicio = "+r.getHoraInicio());
log.write(" horaFin = "+r.getHoraFin());
log.write(" fecha = "+r.getStringFecha();
Sabiendo que “log” y “r” son objetos, ¿Hay algo complicado? ¿Hay algo que no
entiendas? ¡Claro que no!
Constructores
A primera vista, parece que “new” es un CONSTRUCTOR, porque su misión es
construir nuevos objetos. Bueno, pues nooooop. “new” INVOCA a un constructor, NO
ES un constructor. Bueno, no es tan difícil. “new” invoca a un constructor. Vale. ¿Y
qué es un constructor?
Primero: se invoca UNA VEZ para cada objeto. Los métodos de un objeto se
pueden llamar todas las veces que quieras:
Sin embargo, el constructor va a ser invocado una sóla vez, cuando lo diga
“new”.
Bueno, pues una vez dicho esto, vamos a cambiar un poco lo que decíamos sobre
el uso de “new”, y vamos a cambiarlo por:
REFERENCIA
OPERADOR PUNTO “.”
NEW
CONSTRUCTOR
Definición de constructores
Vamos a definir un constructor para la clase Mesa. Nuestra intención, hacer que
cada mesa nueva sea cuadrada, azul y con cuatro patas. Bueno, pues es muy fácil,
añadimos a la clase el método en negrita:
class Mesa {
String color;
int numPatas;
String forma; RECUERDA:
el constructor tiene el
void cambiarColor(String nuevoColor){ mismo nombre que su clase,
color = nuevoColor; no devuelve ningún valor,
} y se define sin “void”
Mesa() {
color = “azul”;
numPatas = 4;
forma = “cuadrada”;
}
}
Margarita será una mesa cuadrada azul de cuatro patas, ¡Una mesa en
condiciones, vaya!
Pero hay un problema: yo no quiero mil mesas iguales. Yo quiero crear una mesa
como a mí me dé la gana, yo no quiero que todas las mesas sean azules y cuadradas con
cuatro patas. ¿Se te ocurre algo para solucionar esto?
¡Podemos definir un constructor con parámetros! Así, cuando creemos una mesa
le daremos su color, su número de patas y su forma iniciales. A ver, sería algo así:
El Polimorfismo
permite tener varios
métodos diferentes entre sí
y con el mismo nombre.
Un buen momento para echarle
un vistazo!
Si te digo la verdad, yo pocas veces uso los constructores con parámetros (que
no significa que sean malos, ¿eh? no te creas......). En su lugar, utilizo los.....
Métodos get/set
supón que en medio del programa quiero cambiar UNA SOLA propiedad de un
objeto. En nuestro caso, puedo cambiar el color. Pero imagina que tengo una mesa roja:
Y quiero hacer que sea amarilla. Bueno, pues tengo dos opciones:
primera: crear una nueva mesa, casi igual:
segunda: definir una serie de métodos que cambien UNA SOLA propiedad del
objeto. A este tipo de métodos se les denomina “métodos set”, porque suelen comenzar
con la palabra “set” (“poner”):
Fíjate tú qué cosas, oche. Ahora resulta que “setColor” y “cambiarColor” hacen
exactamente lo mismo. Prescindiremos de uno de ellos. Por ejemplo, de
“cambiarColor”.
Vamos a definir los métodos “get” de nuestra clase Mesa. Empecemos con el
color. Llamaremos al método “getColor”. Ya que el color es una String, getColor
devolverá una String:
String getColor(){
return color;
}
De forma semejante haremos con getForma:
String getFoma(){
return forma;
}
int getNumPatas(){
return numPatas;
}
Bueno, pues resumimos nuestra clase Mesa; tres propiedades, tres métodos “set”
para definir esas propiedades, tres métodos “get” para obtener el valor de las
propiedades, un constructor con parámeros y otro sin parámetros, y pasamos del
método “cambiarColor”. La clase Mesa está escrita en la siguiente página. Aquí no
cabe....
class Mesa {
String color;
int numPatas;
String forma;
String getColor(){
return color;
}
String getForma(){
return forma;
}
int getNumPatas(){
return numPatas;
}
Mesa() {
color = “azul”;
numPatas = 4;
forma = “cuadrada”;
}
}
Variables de clase. Modificador static.
Supón que tenemos una empresa que publica páginas web en Internet para otras
compañías. Supón que, como empresa que somos, en cada página queremos anunciar
nuestros servicios, por ejemplo, poniendo nuestro número de teléfono. Así, cada vez que
alguien visitase la página de uno de nuestros clientes sabría cuál es nuestro teléfono para
así poder contratar nuestros servicios. Hasta aquí bien, ¿verdad?
Vale. Supón que tenemos una clase paginaGué con las propiedades dirección,
contenido y numeroTeléfono. Cada vez que creemos una página, le daremos un
contenido, una dirección y nuestro número de teléfono. Por supuesto
definimos en la clase todos los métodos set y get necesarios. Creo que eres
Ahora supón que cambiamos nuestra sede y, por tanto, totalmente capaz de
nuestro número de teléfono. escribir la clase
paginaGué
¡Dios! ¡Hemos creado mil páginas web
y ahora tenemos que cambiar el número de
teléfono de todas! ¡Mil llamadas al método
setNumeroTeléfono!
Creo que este ejemplo es muy ilustrativo, ¿verdad? Bueno, pues pasemos a la
acción.
En Java, una propiedad que se comparte por todos los objetos de una clase se
llama “variable (propiedad) de clase” o “estática”. ¿Por qué? La primera denominación
hace referencia a que podemos entender que una variable compartida NO pertenece a los
propios objetos, sino sólo a su clase. Es como si las Ideas de Platón definiesen no sólo
las propiedades y el comportamiento de los objetos físicos, sino que además definiesen
el contenido de alguna propiedad. Si todas las mesas fuesen de madera, la propiedad
“material” de una mesa estaría definida en la Idea de mesa, no en cada mesa.
Bueno, pues es sólo una idea. Respecto al otro nombre, “variable estática”, éste
viene dado porque en Java, para definir una variable compartida se le antepone el
modificados “static”:
Hala. Pues ya está. Añadiendo un “static” antes de una propiedad hacemos que
esa propiedad sea compartida por todos los objetos.
Supón ahora que queremos saber cuántas mesas hemos fabricado. Bueno, pues
vamos a añadir una propiedad estática numMesasFabricadas a la clase Mesa.
Inicialmente, numMesasFabricadas valdrá cero, pero cada vez que un constructor sea
invocado, aumentará en una unidad. Después definiremos un método
getNumMesasFabricadas() para saber cuántas mesas llevaremos creadas. Bueno, pues
la clase Mesa quedaría definida asín (de nuevo, en una hoja aparte):
class Mesa {
String color;
int numPatas;
String forma;
static int numMesasFabricadas = 0;
void setColor(String nuevoColor){
color = nuevoColor;
}
String getColor(){
return color;
}
String getForma(){
return forma;
}
int getNumPatas(){
return numPatas;
}
Mesa() {
color = “azul”;
numPatas = 4;
forma = “cuadrada”;
numMesasFabricadas = numMesasFabricadas + 1;
}
int getNumMesasFabricadas() {
return numMesasFabricadas;
}
}
Y ya está. Ahora, si hacemos:
Por ejemplo, podemos saber cuál es el número de mesas fabricadas sin necesidad
de “preguntárselo” a una mesa determinada. ¡Podemos preguntar a la propia clase Mesa!
Cambiamos el método:
Es decir, que si yo quiero definir una constante, por ejemplo, pi, hago:
static final int pi = 3,1415926535897932384626433832795;
Hala. Ahora pi es una variable compartida por todos los objetos de la clase en la
cual hemos definido la propia pi, y además no puede cambiar de valor. Hala.
VARIABLE COMPARTIDA
MODIFICADOR STATIC
MÉTODO COMPARTIDO
LLAMADAS A MÉTODOS MEDIANTE EL NOMBRE DE LA CLASE
( Mesa.getNumMesasFabricadas() )
MODIFICADOR FINAL
Seguro que te has dado cuenta de que hemos definido mil clases, métodos y
propiedades, pero que realmente todavía no hemos hecho ningún programa. Bueno.
Vamos a solucionar eso.
Un programa suele constar de varios archivos, uno por cada clase que definimos.
Bueno, pues en una de estas clases debemos definir el método main. Como
comprenderás, será una buena práctica de programación definir una clase
exclusivamente para albergar el main. No es necesario, pero es muy buena práctica, es
decir, que al margen de toda nuestra fabulosa colección de clases definimos otra más
cuyo contenido sea un sólo método main. Bueno, pero vamos con el propio método.
El main se define siempre igual, por norma en Java. Es un método:
java clase
y esto invoca a la JVM. Pero nosotros somos muy listos, y podemos arrancar el
programa pasándole argumentos:
Bueno, pues la JVM coge estos argumentos los mete en una lista. A este tipo de
listas se les denomina array, y funciona de la siguiente manera:
Un inciso: arrays
Un array, como una variable cualquiera, tiene un TIPO (int, float, String...) y un
IDENTIFICADOR. Veamos cómo se declaran:
sacabó el inciso.
y crea el array que hemos llamado args. Bueno, Podemos, por ejemplo, escribir
un programa al que le pasemos como argumentos un color y la forma, y él nos cree una
mesa con cuatro patas y con ese color y esa forma. Usando System.out.println
podemos mostrar en pantalla las propiedades de la mesa.
class MesaMain{
public static void main(String[] args) {
Mesa Margarita = new Mesa( args[0], 4, args[1] );
System.out.println(“Hemos creado una mesa”);
System.out.println(“con ”+Margarita.getNumPatas()+” patas,”);
System.out.println(“de color “+Margarita.getColor());
System.out.println(“y de forma “+Margarita.getForma());
}
}
y hacemos:
Sentencias condicionales
sentencia if
if (condición) {
bloque1
} else {
bloque2
}
Si cualquier bloque consta sólo de una sentencia, entonces las llaves
correspondientes a ese bloque pueden eliminarse. Es cuestión de comodidad.
Una expresión booleana es cualquier cosa que pueda dar como resultado TRUE
o FALSE. Por ejemplo, la comparación de dos variables.Este es un buen momento para
ver los comparadores de magnitud:
== igual a
!= diferente de
> mayor que
< menor que
>= mayor o igual que
<= menor o igual que
AND &&
OR ||
NOT !
Otro tipo de expresión booleana puede ser un valor boolean devuelto por un
método. Veamos un ejemplo:
if (num1 == num2){
System.out.prinln(“Son iguales”);
} else {
System.out.println(“Son diferentes”);
}
Sin embargo, para saber si dos String son iguales no podemos utilizar el
simbolo de igualdad. Es una peculiaridad de Java que no viene ahora a cuento:
Aparentemente, si tenemos
if (tal y cual) {
hacemos esto
if (nosequé){
pues esto otro
} else {
y si no, esto
}
} else {
if (vaya rollo){
bah, yo me piro
} else {
paso de todo
}
}
Una sentencia if puede definirse sin su else correspondiente:
if (string1.equals(string2)){
System.out.println(“Son iguales”);
}
.
.
.
Pero hay que tener mucho cuidado con esto, sobre todo si anidamos ifs.
Supongamos que queremos comparar dos enteros n1 y n2, y saber si son iguales o si n1
> n2. No nos importa saber si n2 > n1. Recuerda que cuando un bloque consta sólo de
una sentencia (que puede ser perfectamente una sentencia if), las llaves pueden
eliminarse.
int n1 = 1;
int n2 = 10;
if (n1 != n2)
if (n1 > n2)
System.out.println(“n1 > n2”);
// no comprobamos si n2 > n1
else
System.out.println(“Son iguales”);
int n1 = 1;
int n2 = 10;
if (n1 != n2)
if (n1 > n2)
System.out.println(“n1 > n2”);
else
// cualquier sentencia que no haga nada, por ejemplo
n1 = n1;
else
System.out.println(“Son iguales”);
¡Bueno, hay que pasar siempre por estas cosas! Mucho cuidado cuando anides
ifs, pon siempre sus elses, aunque no hagan nada. Otra opción, tal vez te guste más, es
la siguiente:
int n1 = 1;
int n2 = 10;
if (n1 != n2)
if (n1 > n2)
System.out.println(“n1 > n2”);
else { } // bloque de código vacío
else
System.out.println(“Son iguales”);
int n1 = 1;
int n2 = 10;
if (n1 != n2) {
} else {
System.out.println(“Son iguales”);
}
switch (expresión) {
case caso1:
bloque1
case caso2:
bloque2
.
.
.
}
Bueno, pues esto es fácil. Vamos a ver. expresión es un número entero. Si hay
algún caso que coincida con ese número entero, entonces se ejecutan todos los bloques
que haya a partir de ese caso, no sólo el bloque que corresponde a ese caso. Un
poco raro, ¿no? Bueno, veamos un ejemplo:
switch (n){
case 1:
System.out.println(“uno”);
case 2:
System.out.println(“dos”);
case 3:
System.out.println(“tres”);
}
Date cuenta de que no es necesario poner llaves, sean los bloques como sean,
una sentencia o más.
uno
dos
tres
mientras que si n = 2 se imprimiría
dos
tres
y si n = 3, pues se mostraría
tres
Por la razón que hemos visto. Repito. Se ejecuta el bloque que corresponde al
caso y los bloques siguientes. Por eso, si n = 1, se ejecuta el caso 1 y los siguientes, es
decir, los casos 2 y 3.
¿Hay alguna forma de hacer que se ejecute sólo el caso que corresponda, y que
no se ejecuten los casos siguientes? ¡Pues claro! usando break:
switch (n){
case 1:
System.out.println(“uno”);
break;
case 2:
System.out.println(“dos”);
break;
case 3:
System.out.println(“tres”);
break;
}
uno
a diferencia de antes.
Otra cosa sobre los switches: existe un caso especial, el llamado default. Se
ejecuta este caso si no hay otro caso que corresponda a la expresión:
switch (n){
case 1:
System.out.println(“uno”);
case 2:
System.out.println(“dos”);
case 3:
System.out.println(“tres”);
case default:
System.out.println(“más de tres”);
}
más de tres
uno
dos
tres
más de tres
switch (n){
case 1:
System.out.println(“uno”);
break;
case 2:
System.out.println(“dos”);
break;
case 3:
System.out.println(“tres”);
break;
case default:
System.out.println(“más de tres”);
}
piensa, piensa............
Adivina por qué se llaman así. Nos permiten repetir determinado fragmento
de código un número definido de veces.
while
while (condición){
bloque
}
Un ejemplo:
int n = 0;
System.out.println(“a contar”);
while (n <=10) {
System.out.println(“Voy por el ”+n);
n = n + 1;
}
Bueno, pues está claro, este fragmento inicializa n a cero, y mientras n <= 10
hace lo que está entre llaves, es decir, imprimir el mensaje y aumentar n en una unidad.
Es decir, cuenta de cero a diez.
Por supuesto puedes meter whiles, ifs y todo lo que quieras dentro de un while.
Por estas razones suele haber una regla, que no siempre se cumple, ni tienes por
qué cumplirla, pero es conveniente:
Repito que no es una regla general, que no tiene por qué ser así, pero que
conviene. De hecho, seguir esta regla a veces complica la existencia una barbaridad.
do {
bloque
} while (condición)
for
¿te suena?
int n = 0; // INICIALIZACIÓN
System.out.println(“a contar”);
Bueno, pues for resume estas tres partes en una sola sentencia:
Por ejemplo:
System.out.println(“a contar”);
¿Te percatas de cómo for resume las tres partes en una sola sentencia?
Bueno, ¿Crees que hay más sentencias repetitivas? Pues nooooop. En realidad
puedes hacer una diferenciación muy simple: for se usa cuando sabes cuántas veces se
va a repetir un bucle, y while en caso contrario. Por ejemplo, si vas a recorrer un array
usarás un for porque sabes la longitud del array, sabes su tamaño. Si buscas una letra en
una cadena de caracteres usas un for porque sabes cuántos caracteres tiene esa cadena
(usando el método .length() de la clase String, no lo confundas con el .length sin
paréntesis de un array), pero si esperas a que el usuario introduzca una clave, por
ejemplo, usarás un while porque no sabes cuántas veces va a teclear una clave
incorrecta. Y recuerda, do – while no es más que un caso de while.
¿Sabes que con lo dicho hasta ahora puedes programar cualquier cosa? Bueno,
pero no saltes de alegría hasta haberte convencido de que pilotas los conceptos de
SENTENCIAS CONDICIONALES
IF / ELSE
SWITCH / CASE / CASE ELSE
SENTENCIAS REPETITIVAS
WHILE / DO – WHILE / FOR
Existe otra forma de abordar los problemas que se resuelven mediante sentencias
repetitivas. Es una visión muy diferente y que, desgraciadamente, cuesta mucho
entender. Así que trataré de esforzarme. Es el temido tema de...
Recursividad
pero, fíjate:
entonces,
(n+1)! = (n+1) · n!
y, por tanto,
n! = n · (n-1)!
Vale. Cursillo intensivo de Calculo I. Bueno. Observa que la definición de
factorial engloba un factorial. Por eso es recursivo.
Supón la cola de la taquilla del cine. Si, antes de entrar a ver la película hay unas
cuantas personas comprando la entrada. Aquí las tenemos:
Pero, claro, resulta que el de la camiseta roja tampoco lo sabe. Un fastidio. Así
que lo que hace es preguntárselo al de las rastas, mientras mantiene al de la camiseta
amarilla a la espera.
Pero el de las rastas tampoco lo sabe. Así que hace la misma pregunta al de los
zapatos amarillos, mientras mantiene al de la camiseta roja a la espera. Por supuesto, el
de la camiseta amarilla sigue a la espera de que le responda el de rojo.
En fin, puedes adivinar que el de los zapatos amarillos no tiene ni idea, así que lo
que hace es preguntárselo a la taquillera de los pelos rojos. El de las rastas se queda
esperando a que el de los zapatos amarillos le responda. A todo esto, el de rojo está
esperando al de las rastas, y el de la camiseta amrilla está hartándose de esperar.
Pero ¡vaya! resulta que la taquillera de los pelos rojos, a pesar de ser su primer
día de trabajo, está muy puesta en el tema y sabe la respuesta. Claro, que ella responde a
quien le ha preguntado, al de los zapatos amarillos:
Ahora que el de los zapatos amarillos sabe la respuesta, se la dice al de las rastas,
que le estaba esperando. El de rojo sigue esperando, claro, y el de la camiseta amarilla,
ni te cuento.
Ahora el de las rastas ya sabe la respuesta. Pues va y contesta a quien le ha
preguntado. El de la camiseta amarilla, todavía sigue esperando.
Una vez que el de rojo sabe la respuesta, por fin, se la dice al de la camiseta
amarilla, que es el primero que preguntó, justito antes de que le diera un ataque de
histeria.
Todo método recursivo tiene parámetros y valor de retorno. Es parte del juego.
¿Por qué?
Lo cual ya es una buena razón para pensar que el método necesita parámetros.
Pero, lo mejor de todo, y lo más importante es que el propio método “factorial()”
llamará a “factorial()” pero con otro parámetro. factorial(5) llama a factorial(4), y
éste a factorial(3), y así sucesivamente. Por tanto, es más que obvio que un método
recursivo necesita parámetros. Ufff...
Pensar que un método recursivo no devuelve ningún valor es como pensar que
en la cola del cine el de rojo responde al de amarillo “¡claro! la película empieza a las”.
Joer, imagina la conversación.
Todo método recursivo consta de tres partes. Primero veamos esas partes y luego
te pondré un ejemplo, vale?
El caso base podríamos relacionarlo con la taquillera de los pelos rojos. Ella
puede contestar a la pregunta sin necesidad de preguntar a nadie más, es decir, sin hacer
ninguna llamada recursiva. El caso no base es cualquiera de las personas de la cola:
para resolver la duda han de planteársela a otra persona, no pueden resolverla por sí
mismos. La conquista sería un poco más rara: el paso de la respuesta que a uno le ha
llegado hacia la persona que le ha preguntado. Es decir, el de rojo lleva a cabo la
conquista cuando el de las rastas le responde, y el de rojo toma esa respuesta y se la da
al de amarillo.
Vamos a definir un entero largo, que será la respuesta que el método devolverá:
long respuesta = 0;
Ahora debemos diferenciar entre caso base y caso no base. El caso base será el
factorial de 1, y el caso no base, cualquier otro.
return respuesta;
}
Pues nada, esto compila perfectamente, y funciona. Por cierto, este código no
tiene tratamiento de errores, así que no le hagas perrerías, tipo factorial(-3), porque se te
va a quedar más colgao que el teleférico. Claro, que... ¿Por qué no le haces tú las
medidas de seguridad? No es difícil... ¡Ánimo!
Bueno, ahora voy a contarte un pequeño truco que nadie cuenta para entender
bien el funcionamiento de un método recursivo.
Verás, cuando un método se llama a sí mismo, imagina que lo que ocurre es que
en la memoria del ordenador se hace una copia del método. Así que lo que tú deberías
hacer para entender un método recursivo es pensar que existen varias copias del método
en memoria. Si tienes este código:
if ( numero == 1 ) {
respuesta = 1;
} else {
respuesta = numero * factorial(numero – 1);
}
return respuesta;
}
Hala. Se acabó. ¿Crees que te voy a dejar sin la lista de conceptos? Pues
noooooo...
Como curiosidad....
¿Sabes por qué se le llama “conquista”? Pues es muy sencillo. Los métodos
recursivos se suelen usar para resolver problemas partiéndolos en cachitos más
pequeños. Por ejemplo, buscar a una persona en una cola de gente: primero buscas en la
mitad izquierda, y luego en la derecha. Esto lo verás muy profundamente en Laboratorio
de Programación. Bueno, pues como ya sabrás, hay un refrán árabe que dice: divide y
vencerás. En inglés, “divide and conquer”. De ahí lo de “conquista”.
Bueno, vamos a abordar una de las partes más bonitas de la OOP, aunque trae
sus dolores de cabeza, no te creas. Algunos lenguajes, como C++ basan gran parte de su
ingente potencial en esto que llamamos...
Herencia
Bueno, está claro qué es la herencia. Es lo que unos padres dejan a sus hijos. O
mejor dicho, lo que unos padres transmiten a sus hijos por vía genética. Las personas
somos creadas mediante herencia de genes, a pachas entre papi y mami. En definitiva,
que papá y mamá no nos definen desde el principio, sino que toman sus propios genes
para crearnos a nosotros. Bueno, afortunadamente esto no es tan fácil en genética como
en programación.
Pero el concepto que te tiene que quedar muy claro es que la herencia es un
mecanismo de definición, no un método para suspender a los de primero de Teleco, ni
un galimatías conceptual, sino que es una forma de definir nuevos objetos a partir de
los existentes. La herencia sirve para definir.
En Java una clase sólo puede heredar de otra clase. No se admite que una
clase herede de varias clases, como sí se puede hacer, por ejemplo, en C++. En Java, por
tanto, no hablamos nunca de herencia múltiple. Además, la herencia en Java se
denomina extensión: decimos que una clase extiende a otra.
Por tanto tenemos que tener en cuenta que, en Java, los objetos sólo tienen un
padre, y además, heredan de él el 100%, no como en las personas que heredan el 50%
Bueno, pues sin más preámbulos nos podemos plantear alguna estructura
jerárquica, es decir, algún diagrama de clases en el que dichas clases se relacionen
mediante mecanismos de herencia. Por ejemplo, se me ocurre pensar que una moto es
como una bicicleta con motor. De ahí lo de “motocicleta”. Bieeeeen
class Motor {
void saludar() {
System.out.println(“Soy un motor”);
}
}
class Bicicleta {
Rueda delantera;
Rueda trasera;
Bicicleta(){ // el constructor
delantera = new Rueda();
trasera = new Rueda();
}
void saludar() {
System.out.println(“Soy una bicicleta”);
}
}
Bueno, pues vamos a definir la moto. Para hacer que una clase “hijo” extienda a
otra “padre”, la primera clase se define así:
Moto() { // el constructor
motor = new Motor();
}
void saludar(){
System.out.println(“Soy una amoto”);
}
}
Estas cuatro clases son lo más fácil del mundo. Si no las entiendes, para y vuelve
atrás, porque son de lo más básico. Pero seguro que las entiendes sin problemas,
¿verdad?
Respecto al método saludar, fíjate que Motor redefine el método saludar que
hereda de Bicicleta. La clase padre tenía un método saludar, pero la clase hija también
lo tiene. Se dice que lo redefine (overrides). Sin embargo, debe quedar muy claro que
redefinir un método no implica que el método anterior deje de existir, es decir, que
el método saludar de Bicicleta sigue existiendo a pesar de haberlo redefinido en la
clase moto.
No tendría sentido que una moto saludase como una bicicleta, ¿no? Aunque no
te creas, que gracias al casting, que en breve veremos, podemos hacer que una moto
pueda saludar como moto y como bicicleta.
Bueno, pues eso es todo sobre cómo se usa la herencia. Vemos cómo hemos
definido una moto a partir de la definición de una bicicleta, ¿verdad?. Ahora, en
cualquier parte del código, por ejemplo, en un main podemos hacer sin problemas:
Antonieta.saludar();
Anacleta.saludar();
y cada una nos saludaría diciendo lo que son. Hala. Voy a compilar este código a
ver si da problemas...... no, parece que no los da.
Vamos a plantear una cuestión: una Bici, al crearse, crea las dos ruedas. Una
moto, al crearse, crea un motor. Pero, ¿Se crean las ruedas al crearse la moto? Fíjate en
el constructor de la clase Moto:
Moto() { // el constructor
motor = new Motor();
}
Desgraciadamente no. Tal y como estamos, al crear una moto se crea su motor,
pero no sus ruedas. Ayayayayyyyyy.... ¿cómo arreglamos esto?
Moto() { // el constructor
delantera = new Rueda();
trasera = new Rueda();
motor = new Motor();
}
Moto() { // el constructor
super();
motor = new Motor();
}
entonces, cada vez que creemos una moto se creará “la bicicleta que reside en su
interior” (oh! una lágrima resbala por mi mejilla....) y luego el motor. Es como si
al crear a una persona primero
En definitiva, creas lo que tiene de su
cuando una clase extiende padre y luego creas el
a otra, el constructor de la resto de cosas.
clase hija debe llamar al Una visión muy peculiar,
constructor de la clase madre, ¿no crees?
y esto se hace mediante Por cierto, conviene
super(). que super() sea lo primero que
aparezca en el constructor, antes de
cualquier otra sentencia. ¿Te has preguntado
por qué super() tiene paréntesis? Deberías adivinarlo,
pero por si acaso, te lo digo. super() es el constructor de
la superclase, y recuerda que el constructor no es más que
un método un tanto especialito, pero método al fin y al cabo.
Y si no recuerdas mal, los métodos llevan paréntesis siempre....
nota
Cuando una clase hereda de otra no es necesario que llame al constructor de su superclase, pero
siempre que crees una clase hija, lo más normal es que sí lo haga. Plantéate la lógica de este hecho: supón
un mecánico que sabe que una moto es una bicicleta con motor. Si le piden fabricar una moto, entonces
primero creará una bicicleta y luego le pondrá un motor. Es decir, primero crea la clase padre y luego la
hija. Supón ahora que defines una motopija, que es una moto con aire acondicionado . Pues al crearla,
primero crearás una moto y luego le pondrás el aire. Esto implica crear primero una bicicleta, luego
ponerle motor para hacer la moto, y luego ponerle el aire para hacer la motopija. Vaya, dos super()....
HERENCIA
CLASE PADRE / CLASE HIJO
USO DE extends
REDEFINICIÓN (OVERRIDING) DE MÉTODOS
(que a continuación veremos con más detalle)
USO DE super()
CONCEPTO DE MOTO CON AIRE ACONDICIONADO
Bueno, no tiene nada que ver con actores. Qué pena, ¿verdad?
Casting significa algo así como “convertir”. El objetivo del casting es hacer que
un objeto que se ha definido mediante herencia se comporte como un objeto de una de
sus superclases. Es decir, que una moto salude como una bicicleta, o que una moto deje
de tener motor, o cosas por el estilo. En realidad el casting es algo un poco más
profundo, pero empezaremos por lo fácil. No te creas, acabaremos con lo difícil....
class Bicicleta {
Rueda delantera;
Rueda trasera;
Bicicleta(){ // el constructor
delantera = new Rueda();
trasera = new Rueda();
}
void saludar() {
System.out.println(“Soy una bicicleta”);
}
}
Moto() { // el constructor
super(); // llamamos al constructor de Bicicleta
motor = new Motor();
}
void saludar(){
System.out.println(“Soy una amoto”);
}
}
Si hacemos:
Anacleta.saludar();
veremos en pantalla :
Supón que tenéis una vecina que conoce muy bien a tu madre, mucho mejor que
a ti. Un buen día te ve y te saluda, y te dice “Vaya, tienes los ojos de tu madre”. ¿Por
qué te dice esto? Aparte de porque realmente puede que tengas los ojos de tu madre, la
vecina te lo dice porque conoce a tu madre. Si no la conociese no podría decirlo, ¿no?
Es decir, que la vecina puede decir lo que has sacado de tu madre si conoce a tu madre.
Bueno, pues una referencia, que se supone que ya sabes a la perfección qué es,
es como la vecina. Es capaz de ver en los objetos los rasgos que conoce. Si una
referencia es del tipo bicicleta, entonces verá los contenidos propios de la bicicleta en el
objeto al que apunte. Por ejemplo:
refAOtraBicicleta.saludar();
veremos
¡aunque refAOtraBicicleta apunta a una moto!. ¿Por qué? Pues por lo dicho,
porque refAOtraBicicleta no conoce el método que saluda como una moto, sólo
conoce el método que saluda como una bicicleta. Pretender que refAOtraBicicleta
haga saludar a la moto como si fuese una moto sería como pretender que la vecina te
diga que tienes las manos de tu abuelo, al que nunca conoció. Aquí tienes un pequeño
gráfico que tal vez te ayude:
Vamos a olvidar por ahora los constructores, ¿vale? Bueno, pues ¡te presento a la
señora referencia de tipo Bicicleta!:
¡¡¡TACHAAAAAAN!!!
Bueno, pues ¿Por qué la referencia de tipo Bicicleta tiene esa forma? Pues fjate
en cómo funciona esta referencia con un objeto de tipo Bicicleta:
Por supuesto, huelga decir que una referencia de tipo Bicicleta no puede apuntar
a objetos que ni sean bicicletas ni hereden de bicicletas. Es decir, que una referencia de
tipo bicicleta no puede apuntar a la mesa Margarita. Lástima.
Espero que ahora haya quedado bien explicado, o mejor dicho, bien mostrado:
Bueno, acabas de ver cómo funciona una referencia. Como resumen, una
referencia es un conjunto de flechitas que apuntan hacia determinados contenidos de un
objeto. Los contenidos a los que apuntan vienen determinados por el tipo de la
referencia.
Comparación de referencias
Margarita == Catalina
Pues veamos: estamos comprobando si son iguales dos referencias. Cada una de
ellas apunta a una mesa cuadrada, azul y de tres patas. Así que, como son iguales, esto
debería dar TRUE.
Pues no.
Fíjate: las dos mesas son azules, de tres patas y cuadradas. PERO SON DOS
MESAS DIFERENTES, no son la misma mesa. Es como decir que dos gemelos, por ser
idénticos, son la misma persona. Bueno, ten esto muy presente siempre, ¿vale? Puedes
comparar dos númeos con ==, pero no dos objetos.
Antes de seguir asegúrate que has alcanzado la Idea platónica de los dos puntos
anteriores. Si no es así, en realidad lo único que tienes que hacer es pensar muy
profundamente en ello, vuelve a escribir las clases, prueba a hacer pequeños
programas... recuerda lo dicho en el prefacio. Y, por supuesto, si tienes más probelmas,
aquí estoy.
Supón ahora que se nos pincha una rueda de la bicicleta. Pues la llevaremos a un
taller:
class Taller {
void arreglar(Bicicleta bici){
System.out.println(“A arreglar!”);
}
}
es decir, creamos una bici, un taller, y hacemos que el taller arregle la bici
después de mucho montar. Bueno, pues esto no parece complicado, ¿verdad?
Crearemos primero una moto, pero tendrá una referencia de tipo bicicleta:
¿Te da cuen? Si arreglar necesita una bicicleta y queremos arreglar una moto,
hacemos que una referencia de tipo bicicleta apunte a una moto.
Bueno, pues fíjate para qué sirve esto de las referencias. ¿Te gusta? Pues verás
ahora.
Un taller que se precie no sólo debe ser capaz de arreglar pinchazos. También
debería poder cambiar el aceite a los motores, ¿no? Bueno, pues vamos a definir otro
método de la clase Taller.
class Taller {
void arreglar(Bicicleta bici){
System.out.println(“A arreglar!”);
}
Bueno, pues ahora tenemos un peazo taller de la leche. Si tenemos una moto
cualquiera podemos arreglarle los pinchazos y cambiarle el aceite. Pero fíjate, el método
cambiarAceite requiere que le pasemos una moto (porque cambiar el aceite a una bici
se las traería, ¿no?), pero arreglar requiere una bicicleta. Madre mía. ¡Necesitamos una
referencia de tipo Bicicleta para arreglar la moto y otra de tipo Moto para cambiarle el
aceite!
elTaller.cambiarAceite(refMoto);
Pero, para arreglar las ruedas necesitábamos una referencia de tipo bicicleta, y la
referencia que tenemos es de tipo Moto. Tendremos que crear una nueva referencia:
Esta referencia nueva apunta al mismo objeto al que apuntaba refMoto. Ahora sí
es lícito hacer
elTaller.arreglar(refBicicleta);
Bueno, pues esto es perfectamente legal, funciona. Pero coincidirás conmigo que
es un engorro. Tener dos referencias de tipo distinto para un mismo objeto no es ser
muy ahorrativo. Ni muy práctico, todo sea dicho.
Casting
Como dijimos hace una eternidad, “casting” es algo así como “convertir”. El
objetivo es el siguiente:
Hemos visto casos en los que un objeto necesita varias referencias de distinto
tipo, como con el taller: arreglar las ruedas necesita una bicicleta, pero cambiar el aceite
necesita una moto. Para cambiar el aceite a una moto no hay mucho problema, pero para
arreglarle las ruedas había que hacer una nueva referencia de un tipo diferente.
Bueno, pues existe una manera de hacer esto mismo con una sola referencia.
¿Cómo? Pues muy fácil: convirtiéndola.
(tipo final)referencia
(Bicicleta)refMoto
y, por fin....
elTaller.cambiarAceite(Maroto);
elTaller.arreglar( (Bicicleta)Maroto ); // esto es casting!!!!!!!!!
Tenemos una sola referencia, llamada Maroto que es de tipo Moto, pero
podemos usar esta referencia de tipo Moto en métodos que requieran una referencia de
tipo Bicicleta (como el método arreglar) porque podemos convertirla. ¡BIEN!
1. Una moto puede saludar como una bici. Podemos hacer que un objeto de un
tipo se comporte como un objeto de otro tipo.
2. El método arreglar ve a una moto como si fuese una bici, mientras que
cambiarAceite ve la misma moto como lo que realmente es, una moto.
Podemos hacer que un método vea a un objeto como si fuese de una clase y
que otro método vea el mismo objeto como si fuese de otra clase.
REFERENCIA
TIPO DE UNA REFERENCIA
CÓMO las referencias apuntan a un objeto
CÓMO dos referencias de diferentes tipos ven contenidos diferentes de un
mismo objeto
COMPARACIÓN DE REFERENCIAS: == no funciona como quisiéramos....
CÓMO un método requiere referencias de determinado tipo (como parámetros)
SENTIDO DE usar distintas referencias para un objeto
FINALIDAD DEL CASTING
SINTAXIS DEL CASTING
¡Recuerda!
class A {
int getn() {
return 1;
}
}
class B extends A {
int getn() {
return 2;
}
}
class ABMain {
public static void main(String[] args){
A a = new A();
B b = new A();
System.out.println(“numero:”+a.getn());
System.out.println(“numero:”+b.getn());
}
}
Este apartado es muy corto y sólo sirve para que aprendamos un par de términos.
Sólo hay un pequeño problema: es un pelín enrevesado. Trataré de explicarlo
fácilmente, pero eso no va a ser suficiente. Así que abre bien los ojos y lee cada párrafo
siete veces. Para hacerlo más corto aún, vamos a seguir con la bicicleta y la moto como
ejemplos, ¿vale?
(Bicicleta)Maroto
Downcasting: lo contrario:
(Moto)Anacleta
class A {
int getn() {
return 10;
}
}
class B extends A {
int getm() {
return 20;
}
}
class C {
void pillaUnA ( A j ){
System.out.println("n = "+j.getn());
}
void pillaUnB ( B j ) {
System.out.println("m = "+j.getm());
}
}
c.pillaUnA(a);
c.pillaUnA(b);
c.pillaUnA( (A)b );
c.pillaUnB(b);
c.pillaUnB(a);
A a = new A();
C c = new C();
c.pillaUnB( (B)a );
UPCASTING
DOWNCASTING
CASTING IMPLÍCITO
CASTING EXPLÍCITO
Ejercicio:
Dado el siguiente main, ¿Qué sentencias son lícitas? ¿cuáles compilan y cuáles
no? ¿cuáles tienen upcasting y downcasting? ¿Cuáles tienen casting implícito y cuáles
explícito?
c.pillaUnA(a);
c.pillaUnA(b);
c.pillaUnA ( (A)b );
c.pillaUnA ( (B)a );
c.pillaUnB (a);
c.pillaUnB (b);
c.pillaUnB ( (A)b );
c.pillaUnB ( (B)a );
}
Solución:
c.pillaUnA(a); // normal
c.pillaUnA(b); // upcasting implícito
La Clase Object
La Clase Object es una clase que Java tiene definida en sí mismo con su propio
mecanismo. Es decir, que no vas a tener que definirla, así que tranki.
La clase Object se define como superclase de toda clase Java. Es decir, que si
defines una clase cualquiera, será una clase que herede de la clase Object, aunque no lo
definas como tal. La clase Mesa o Bicicleta son, en realidad, extensiones de Object.
Fíjate qué cosas.
Bien. ¿Qué contenidos tiene la clase Object? Pues esta clase tiene unos métodos
muy extraños:
Sin embargo, estos métodos sirven para todo tipo de objetos. Por lo que no es
difícil adivinar que serán todos métodos muy generales. Así que lo más probable es que,
si quieres utilizar uno de estos métodos, tendrás que redefinirlo (override).
class Florero {
void saludar(){
System.out.println(“Soy un florero”);
}
}
class Foto {
void saludar(){
System.out.println(“Soy una fotografía”);
}
}
class Lampara {
void saludar(){
System.out.println(“Soy una lámpara”);
}
}
Bueno, pues el objetivo de nuestro programa es escribir un método que
meteremos en la clase Mesa (¿te acuerdas de ella?) que sirva para colocar cosas encima
de una mesa. Recuerda la clase Mesa:
class Mesa {
String color;
int numPatas;
String forma;
static int numMesasFabricadas = 0;
String getColor(){
return color;
}
String getForma(){
return forma;
}
int getNumPatas(){
return numPatas;
}
Mesa(String colorInicial,
int numPatasInicial,
String formaInicial){
color = colorInicial;
numPatas = numPatasInicial;
forma = formaInicial;
numMesasFabricadas = numMesasFabricadas + 1;
}
Mesa() {
color = “azul”;
numPatas = 4;
forma = “cuadrada”;
numMesasFabricadas = numMesasFabricadas + 1;
}
int getNumMesasFabricadas() {
return numMesasFabricadas;
}
}
A primera vista se nos ocurre hacer un método para cada tipo de objeto a
colocar, es decir, escribir un ponerEncimaUnFlorero, PonerEncimaUnaLampara,
ponerEncimaUnaFoto, más o menos así:
Bueno, pues ahora vamos a hacer uso de la clase Object. Como es la superclase
de toda clase Java, podemos hacer un método que coloque cualquiera de los objetos
anteriores:
Hala. Revive este pequeño capítulo sobre la clase Object y no sigas adelante si
no has entendido a la perfección:
CLASE OBJECT
SU CONTENIDO
SU USO COMO REFERENCIA GLOBAL (para toda clase Java)
Ejercicio:
Plantéate los siguientes fragmentos de código
En definitiva, si esta parte te ha parecido lo peor, siento que haya sido así, y
espero y deseo de corazón que encuentres fácilmente una explicación mejor. Por cierto,
el pez, el pato y el pájaro que no tengo ni idea de cómo se llama, también te piden
disculpas.
Bueno, pues estos tres bichos también te animan a seguir adelante, ya que queda
muy poco. De verdad. Lo prometo. Bueno, abordemos ahora un tema bastante curioso.
Son las...
Interfaces
Vamos a ver.
El objetivo de una interface es definir qué contenidos debe tener una clase
obligatoriamente. Es algo así como un contrato: una clase puede implementar una
interface si se compromete a definir determinados contenidos. Veamos.
Las interfaces, repito, definen qué contenidos debe tener una clase. Por ejemplo,
qué métodos debe tener obligatoriamente, pero no define esos métodos. Es decir, que
una interface sólo es una colección de cabeceras de métodos. La clase que implemente
esa interface debe implementar esos métodos. Lo vemos con un ejemplo: Si definimos:
interface Trabajador {
void pagarImpuestos();
}
Entonces, toda persona que sea trabajador, trabaje en lo que trabaje, debe
implementar esta interface:
void pagarImpuestos(){
System.out.println(“Como funcionario, pago mis impuestos”);
sueldo = sueldo – (0.16*sueldo);
}
}
void pagarImpuestos(){
System.out.println(“O sea, yo pago un plussss”);
sueldo = sueldo – (0.30*sueldo);
}
}
¿Te das cuenta? Tenemos dos personas diferentes, que nada tienen que ver la una
con la otra, excepto una cosa: que ambas son trabajadoras. Así, deben pagar impuestos.
Pero fíjate que cada una lleva a cabo ese pago de forma diferente. La Interface
Trabajador no determina cómo va a llevarse a cabo tal pago, solamente exige que
se lleve a cabo.
Bueno, creo que hasta ahora todo va más o menos bien, ¿no? Ahora vamos a por
lo mejor de las interfaces.
¿Lo has pillado? En realidad, el objetivo de una interface es que una clase A
pueda comunicarse con otra clase B independientemente de cómo B esté escrita. Por
ejemplo: supón que ahora definimos la clase Hacienda. Esta clase exigirá a todos los
trabajadores que paguen sus impuestos. Pero hay miles de trabajadores distintos, unos
son funcionarios, otros presentadores, pero otros son otras cosas. Sin embargo,
Hacienda juega con un as en la manga: como hemos exigido que cada trabajador, sea
como sea, implemente a la interface Trabajador, podemos referenciar a cualquier
clase que implemente a Trabajador mediante una referencia de tipo Trabajador:
class Hacienda {
.
.
.
void quePagueElCurrante(Trabajador currante) {
currante.pagarImpuestos();
}
}
Joer, qué cosa. Resulta que al método quePagueElCurrante le pasamos como
parámetro cualquier objeto que implemente a la interface Trabajador, y éste método se
encarga de hacer que pague. ¿Te fijas? Primero: no nos importa quñe tipo de trabajador
sea, sólo nos importa que implemente a Trabajador. Segundo: La referencia a este
objeto es de tipo Trabajador, no es ni Presentador ni Funcionario ni nada.
malditaHacienda.quePagueElCurrante( Fulgencio );
malditaHacienda.quePagueElCurrante( JesusVazquez );
Cuando una clase hereda de otra, hereda todos sus contenidos. En las Interfaces
no se definen contenidos, por lo que no se puede hereda ningún contenido. Una interface
no es una clase, como lo son las superclases en la herencia, por lo que una interface no
se puede instanciar:
Una clase puede implementar varias interfaces a la vez, pero no puede heredar de
varias clases a la vez. NO EXISTE LA (maravillosa) HERENCIA MÚLTIPLE EN
JAVA, diga lo que diga tu profesor (vale, pero si te lo pregunta en el examen responde
lo que él diga!). Las Interfaces pueden parecer un mecanismo de herencia múltiple, pero
no es así en realidad.
Ya hemos acabado.
Epílogo
¿Por qué estas lagunas? Muy sencillo: porque mi intención no es enseñarte Java
a fondo, (eso lo hará el “mastering Java” se la editorial SUN) sino enseñarte a
programar en OOP. ¿Y eso? Fácil: si sabes programar, entenderás cualquier cosa
fácilmente. Cuando hayas leído todo este mamotreto de letras y dibujos, y cuando lo
entiendas a la perfección, no te costrará aprender a usar flujos de entrada y salida en
disco, manejo de excepciones, acceso restringido a miembros de clase, o yo qué sé.
Tal vez algún día escribas tú la segunda parte de “Java para aprobar” explicando
todo lo que me he dejado atrás. Sería muy bonito. Si quieres, te paso los JPG del pez, el
pato y el pajaro ese que no sé cómo se llama.
Bueno, aquí acabamos. Espero que no se te haya hecho muy tedioso (jeeee, que
iluso soy). Pásalo bien, estudia mucho, pregunta lo que quieras y sácale partido a todo
esto, ¿vale?
Once upon a time, somewhere in Eastern Europe, there was a great famine.
People jealously hoarded whatever food they could find, hiding it even from
their friends and neighbors. One day a peddler drove his wagon into a village,
sold a few of his wares, and began asking questions as if he planned to stay
for the night.
"There's not a bite to eat in the whole province," he was told. "Better keep
moving on."
"Oh, I have everything I need," he said. "In fact, I was thinking of making
some stone soup to share with all of you." He pulled an iron cauldron from his
wagon, filled it with water, and built a fire under it. Then, with great
ceremony, he drew an ordinary-looking stone from a velvet bag and dropped it
into the water.
By now, hearing the rumor of food, most of the villagers had come to the
square or watched from their windows. As the peddler sniffed the "broth" and
licked his lips in anticipation, hunger began to overcome their skepticism.
"Ahh," the peddler said to himself rather loudly, "I do like a tasty stone
soup. Of course, stone soup with CABBAGE -- that's hard to beat."
The village butcher managed to find some salt beef...and so it went, through
potatoes, onions, carrots, mushrooms, and so on, until there was indeed a
delicious meal for all. The villagers offered the peddler a great deal of
money for the magic stone, but he refused to sell and traveled on the next
day. And from that time on, long after the famine had ended, they reminisced
about the finest soup they'd ever had.