SCJP 6 Clase 1.5 – Ejemplos de

enum

Ezequiel Aranda

Sun Microsystems Campus Ambassador

Disclaimer & Acknowledgments

> Even though Ezequiel Aranda is a full-time employee of Sun Microsystems, the contents here are created as his own personal endeavor and thus does not reflect any official stance of Sun Microsystems.

> Sun Microsystems is not responsible for any inaccuracies in the contents.

> Acknowledgments – The slides of this presentation are made from “SCJP Unit 2” by Warit Wanwithu and Thanisa Kruawaisayawan and SCJP Workshop by P. Srikanth.

> This slides are Licensed under a Creative Commons Attribution – Noncommercial – Share Alike 3.0 > http://creativecommons.org/licenses/by-nc-sa/3.0/

Pre Java 5.0

> Antes de Java 5, la forma estándar de representar una enumeración, era utilizar el pattern “int Enum”

public static final int SEASON_WINTER = 0; public static final int SEASON_SPRING = 1; public static final int SEASON_SUMMER = 2; public static final int SEASON_FALL = 3;

> Este pattern tenía muchos problemas (no tenían namespace, no eran typesafe, brittleness, información nula al imprimirlos).

Java 5.0

> Soporta enums como un tipo.

> Son una clase.

> Por lo tanto, pueden tener métodos y variables, implementar interfaces, y más.

> Proveen implementaciones de los métodos heredados de Object.

> Son Comparables y Serializables.

Ejemplo – Mazo de cartas

import java.util.*;

public class Card { public enum Rank { DEUCE, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN, JACK, QUEEN, KING, ACE }

public enum Suit { CLUBS, DIAMONDS, HEARTS, SPADES }

private final Rank rank; private final Suit suit; private Card(Rank rank, Suit suit) { this.rank = rank; this.suit = suit; }

public Rank rank() { return rank; } public Suit suit() { return suit; } public String toString() { return rank + " de" +

suit; }

private static final List<Card> protoDeck = new ArrayList<Card>();

// Initializa el mazo static { for (Suit suit : Suit.values()) for (Rank rank : Rank.values()) protoDeck.add(new Card(rank, suit)); }

public static ArrayList<Card> newDeck() { return new ArrayList<Card>(protoDeck); // Retorna

una copia del mazo. } }

Ejemplo – Mazo de cartas (II)

> toString() de Card toma ventaja de toString de Rank y Suit.

> El constructor de Card toma un Rank y un Suit.

> values() retorna un array que contiene los elementos del enum.

Ejemplo – Repartir las cartas import java.util.*;

public class Deal { public static void main(String args[]) { int numHands = Integer.parseInt(args[0]); int cardsPerHand = Integer.parseInt(args[1]); List<Card> deck = Card.newDeck(); Collections.shuffle(deck); for (int i=0; i < numHands; i++) System.out.println(deal(deck, cardsPerHand)); }

public static ArrayList<Card> deal(List<Card> deck, int n) { int deckSize = deck.size(); List<Card> handView = deck.subList(deckSize-n, deckSize); ArrayList<Card> hand = new ArrayList<Card>(handView); handView.clear(); return hand; } }

Ejecución de “Deal”

$ java Deal 4 5 [FOUR of HEARTS, NINE of DIAMONDS, QUEEN of SPADES, ACE of SPADES, NINE of SPADES]

[DEUCE of HEARTS, EIGHT of SPADES, JACK of DIAMONDS, TEN of CLUBS, SEVEN of SPADES]

[FIVE of HEARTS, FOUR of DIAMONDS, SIX of DIAMONDS, NINE of CLUBS, JACK of CLUBS]

[SEVEN of HEARTS, SIX of CLUBS, DEUCE of DIAMONDS, THREE of SPADES, EIGHT of CLUBS]

Agregar operaciones public enum Planet { MERCURY (3.303e+23, 2.4397e6), VENUS (4.869e+24, 6.0518e6), EARTH (5.976e+24, 6.37814e6), MARS (6.421e+23, 3.3972e6), JUPITER (1.9e+27, 7.1492e7), SATURN (5.688e+26, 6.0268e7), URANUS (8.686e+25, 2.5559e7), NEPTUNE (1.024e+26, 2.4746e7), PLUTO (1.27e+22, 1.137e6);

private final double mass; // in kilograms private final double radius; // in meters Planet(double mass, double radius) { this.mass = mass; this.radius = radius; }

public double mass() { return mass; } public double radius() { return radius; }

// universal gravitational constant (m3 kg-1 s-2) public static final double G = 6.67300E-11;

public double surfaceGravity() { return G * mass / (radius * radius); } public double surfaceWeight(double otherMass) { return otherMass * surfaceGravity(); } }

Calcular nuestro peso en cualquier planeta public static void main(String[] args) { double earthWeight = Double.parseDouble(args[0]); double mass = earthWeight/EARTH.surfaceGravity(); for (Planet p : Planet.values()) System.out.printf("Your weight on %s is %f%n", p, p.surfaceWeight(mass)); } $ java Planet 175 Your weight on MERCURY is 66.107583 Your weight on VENUS is 158.374842 Your weight on EARTH is 175.000000 Your weight on MARS is 66.279007 Your weight on JUPITER is 442.847567 Your weight on SATURN is 186.552719 Your weight on URANUS is 158.397260 Your weight on NEPTUNE is 199.207413 Your weight on PLUTO is 11.703031

SCJP 6 Clase 2 – POO

AGENDA

> Encapsulamiento

> Herencia (es un / tiene un)

> Polimorfismo

> Interfaces

> Valores de retorno legales

> Constructores

> Métodos y variables estáticas

Encapsulamiento

> Oculta ciertos elementos de la implementación de una clase proveyendo una interfaz pública para los clientes.

> Mantiene las variables de instancia protegidas (private).

> Se utilizan métodos de accesos públicos, forzando su utilización en vez de el acceso directo a las variables de instancia (set<Propiedad>, get<Propiedad>).

Encapsulamiento

Datos Objeto A

Datos Objeto B

ObjetoB.Metodo1()

Valor de retorno

Herencia

> El lenguaje Java permite que una clase herede funcionalidad de una única clase.

> Esto se conoce como “herencia simple”.

Scanner Impresora

Fotocopiadora Fútbol Rugby

Deporte

✔✖

Relaciones “es un”

> En POO, el concepto de “es un” se basa en la herencia de clases o implementación de interfaces. “Es un” es una forma de decir “Esta cosa es un tipo de esa otra”.

Auto

Auto Deportivo

Relaciones “Tiene un”

> Están basadas en el uso, más que en la herencia. En otras palabras, la clase A tiene un B si el código en la clase A tiene una referencia a una instancia de la clase B.

> Por ejemplo: un caballo ES UN animal y TIENE UN cabestro. Escrito en Java, sería algo como:

public class Animal {} public class Caballo extends Animal { private Cabestro miCabestro; }

Polimorfismo

> Las invocaciones polimorficas a métodos sólo aplican a métodos de instancia.

> Siempre podremos referirnos a un objeto con una variable de un tipo más general (una superclase o interfaz).

> Por lo tanto, podemos hacer cosas como:

Auto a = new AutoDeportivo();

Pregunta

public class Employee{ public void printDetail(){ system.out.println(“Employee”); } } public class Manager extends Employee{ public String department = “Marketing”; public void printDetail(){ system.out.println(“Manager”); } }

> Si hiciéramos Employee e = new Manager(), ¿podríamos usar la variable department? ¿y que resultado tendría la llamada a e.printDetail()?

Sobrescritura de métodos

> Siempre que tengamos una clase que herede un método de una superclase, tendremos la posibilidad de sobrescribir dicho método.

> Salvo que tal método sea final o static.

> El número y el tipo de los argumentos DEBEN ser iguales.

Sobrescritura de métodos (II)

> El tipo a retornar debe ser el mismo (desde Java 5.0, puede ser un subtipo del tipo retornado por el método sobrescrito – tipos covariantes).

> No puede ser menos accesible. Un modificador más amplio sí es valido.

> No debe arrojar nuevas excepciones o excepciones más amplias que las declaradas por el método sobrescrito.

Invocar la versión presente en la superclase de un método sobrescrito

public class Animal { public void eat() { } public void printYourself() { // código de impresión } }

class Horse extends Animal { public void printYourself() { super.printYourself(); // Invocamos el código //presente en Animal // Luego agregamos código específico debajo } }

Sobrecarga de métodos

> La sobrecarga de métodos permite reusar el mismo nombre de un método en una clase, pero con una lista de argumentos diferente.

> Un método sobrecargado DEBE cambiar la lista de argumentos respecto del original.

> Un método sobrecargado PUEDE cambiar el tipo del valor de retorno respecto del original.

Sobrecarga de métodos (II)

> Un método sobrecargado PUEDE cambiar su modificador de acceso respecto del original.

> Un método sobrecargado PUEDE declarar nuevas o más amplias excepciones que el original.

> Un método puede sobrecargarse en la misma clase o en una subclase.

¿Cual es el resultado de este código?

class Car { } class BMW extends Car { } class UsedCar{ public void doStuff(Car b) { System.out.println("In the Car version"); } public void doStuff(BMW b) { System.out.println("In the BMW version"); } public static void main (String [] args) { UsedCar uc= new UsedCar(); Car c = new Car(); BMW b = new BMW(); Car carRefToBMW= new BMW(); uc.doStuff(c); uc.doStuff(b); uc.doStuff(carRefToBMW); } }

En resumen…

> La elección sobre que versión de un método sobrescrito llamar, es hecha en tiempo de ejecución, y se basa en el tipo del objeto.

> Mientras que la elección sobre que versión de un método sobrecargado llamar se basa en el tipo de la referencia del argumento que se pasa en tiempo de compilación.

Casting de variables de referencia

> Hacia abajo: > Manager m = (Manager) new Empleado();

> Hacia arriba: > Empleado e = (Empleado) new Manager();

Ingeniero Manager

Empleado

Casting de variables de referencia (II)

> El compilador es forzado a confiar en nosotros cuando hacemos un casting “hacia abajo”, incluso cuando está mal.

> Por lo que cuando hagamos algo como: > Manager m = (Manager) new Empleado();

El resultado será la aparición de una excepción java.lang.ClassCastException en tiempo de ejecución.

Implementando una interfaz

> Al implementar una interfaz, estamos aceptando adherirnos al contrato definido por esa interfaz.

> Implica que deberemos proveer implementaciones “legales” de todos los métodos definidos en tal interfaz.

> Las clases que implementan una interfaz deben seguir las mismas reglas que las clases que extienden clases abstractas.

Implementando una interfaz (II)

> Proveer implementaciones no abstractas para todos los métodos de la interfaz declarada.

> Seguir todas las reglas para sobrescrituras.

> Declarar solo las mismas excepciones que aquellas declaradas en el método de la interfaz, o subclases de esas excepciones.

> Mantener la signatura y el tipo de retorno (o un subtipo). No es necesario declarar las excepciones.

Pregunta

Interface A { void methodA(); } public class Temp implements A{ void methodA() { } }

> ¿Compila? ¿Por qué? ? ?

Implementando una interfaz (III)

> Cuando declaramos métodos en una interfaz, el compilador los generará con los modificadores public abstract.

> Cuando declaramos atributos en una interfaz, el compilador los generará con los modificadores static final.

Implementando una interfaz (IV)

> Por lo tanto, podremos hacer cosas como:

> abstract class Ball implements Bounceable

> public class Ball implements Bounceable, Serializable, Runnable

> public interface Bounceable extends MoveRunnable

Reglas respecto de interfaces

> class Foo{ } // OK

> class Bar implements Foo{ } //no se puede “implementar” una clase

> interface Baz{ } // OK

> interface Fi{ } // OK

> interface Fee implements Baz{ } // una interfaz no puede implementar una interfaz

>  interface Zee implements Foo{ } // una interfaz no puede implementar una clase

>  interface Zoo extends Foo{ } // una interfaz no puede extender una clase

Reglas respecto de interfaces (II)

> interface Boo extends Fi { } // OK. Una interfaz puede extender una interfaz

> class Toonextends Foo, Button { } // Una clase no puede extender múltiples clases

> class Zoom implements Fi, Fee { } // OK. Una clase puede extender múltiples interfaces

> interface Vroom extends Fi, Fee { } // OK. Una interfaz puede extender múltiples interfaces

> class Yow extends Foo implements Fi { } // OK. Pero extends debe ir primero

public abstract interface Frobnicate { public void twiddle(String s); }

> ¿Cuales declaraciones de clase son correctas?

A. public abstract class Frob implements Frobnicate { public abstract void twiddle(String s) { } }

B. public abstract class Frob implements Frobnicate { }

C. public class Frob extends Frobnicate { public void twiddle(Integer i) { } }

D. public class Frob implements Frobnicate { public void twiddle(Integer i) { } }

E. public class Frob implements Frobnicate { public void twiddle(String i) { } public void twiddle(Integer s) { } }

Valores de retorno

> En los métodos sobrecargados, no podemos cambiar sólo el tipo de retorno.

public class Foo{ void go() { } } public class Bar extends Foo{ String go() { // No legal return null; } }

Valores de retorno (II)

> Métodos sobrescritos – A partir de Java 5, el tipo retornado en un método puede ser un subtipo del tipo retornado en el método (de la superclase) que este está sobrescribiendo.

Valores de retorno (III)

class Alpha { Alpha doStuff(char c) { return new Alpha(); } }

class Beta extends Alpha { Beta doStuff(char c) { // legal en Java 1.5 return new Beta(); } }

Valores de retorno (IV)

> En un método que retorna un tipo primitivo, podemos retornar un valor o variable que pueda ser convertido implicitamente en el tipo de retorno declarado.

public int foo() { char c = 'c'; return c; // char es compatible con int

}

Valores de retorno (V)

> En un método que retorna un tipo primitivo, podemos retornar un valor o variable que pueda ser explicitamente convertidoen el tipo de retorno declarado.

public int foo() { float f = 32.5f; return (int)f; }

Pregunta

1. class Programmer { 2. Programmer debug() { return this; } 3. } 4. class SCJP extends Programmer { 5. // insertar el código aquí 6. }

> ¿Cual de estas líneas hará que el programa compile? (pueden ser varias) > A. Programmer debug() { return this; }

> B. SCJP debug() { return this; }

> C. Object debug() { return this; }

> D. int debug() { return 1; }

> E. int debug(int x) { return 1; }

> F. Object debug(int x) { return this; }

Constructores e instanciación

> Los constructores son el código que se ejecuta siempre que utilizamos la palabra “new”.

> No solo se ejecuta el constructor de la clase, sino también todos los constructores de las superclases.

> Todas las clases, incluso las abstractas DEBEN tener un constructor.

Constructores

> Dos puntos clave a tener en cuenta acerca de los constructores es que no deben tener tipo de retorno y sus nombres deben ser exactamente los mismos que los de las clases a las que pertenecen. En general, se los utiliza para inicializar los estados de las variables de instancia:

class Foo{ int size; String name; Foo(String name, int size) { this.name = name; this.size = size; } }

Constructores (II)

> Caballo c = new Caballo();

> ¿Qué sucede realmente ante esta llamada? (asumiendo que Caballo extiende Animal y Animal extiende Object).

1.  Main llama a new Caballo(). 2.  Caballo llama a super(). 3.  Animal llama a super(). 4.  Object().

Reglas para constructores

> Pueden usar cualquier modificador de acceso.

> Es legal (aunque bastante estúpido) tener un método con el mismo nombre que la clase.

> Si no creamos un constructor, el compilador agregará uno automáticamente (sin argumentos)

Reglas para constructores (II)

> Si ya tenemos un constructor con argumentos, no se generará uno sin argumentos automáticamente.

> Cada constructor tiene, como primera sentencia, una llamada a un constructor sobrecargado (this) o a un constructor de la superclase (super), aunque esta línea puede ser agregada automáticamente por el compilador.

> Los constructores no se heredan ni pueden sobrescribirse (no son métodos)

Reglas para constructores (III)

> Si tu superclase no tiene un constructor sin argumentos, deberás tipear un constructor en la subclase dado que necesitarás un lugar desde donde llamar a super con los argumentos necesarios.

class Animal { Animal(String name) { } } class Horse extends Animal { Horse() { super(); // Problema } }

class Top { public Top(String s) { System.out.print("B"); } } public class Bottom2 extends Top { public Bottom2(String s) { System.out.print("D"); } public static void main(String [] args) { new Bottom2("C"); }} ¿Cual es el resultado?

A.  BD B.  DB

C.  BDC

D.  DBC

E.  Falla la compilación.

? ?

Sobrecarga de constructores

> Los constructores se sobrecargan típicamente para proveer formas alternativas de instanciar objetos de nuestra clase.

> Una llamada a this() es retrasar lo inevitable, alguno de los constructores deberá llamar a super().

> Regla clave: la primera línea de un constructor debe ser una llamada a super() o una llamada a this().

public class Animal { String name; Animal(String name) { this.name = name; }

Animal() { this(makeRandomName()); }

static String makeRandomName() { int x = (int) (Math.random() * 5); String name = new String[]

{"Fluffy","Fido","Rover", "Spike","Gigi"}[x]; return name; } }

class Uber { static int y = 2; Uber(int x) { this(); y = y * 2; } Uber() { y++; } } class Minor extends Uber { Minor() { super(y); y = y + 3; } public static void main(String [] args) { new Minor(); System.out.println(y); } }

> ¿Cuál es el resultado?

A. 6 B.  7 C.  8 D. 9 E.  Falla la compilación.

Pregunta

> ¿Qué pasará si tratamos de compilar el siguiente código? ¿Dónde podría ir la llamada a super()?

class A { A() { this("foo"); } A(String s) { this(); } }

? ?

Variables y métodos estáticos

> Supongamos que tenemos un método en una clase utilitaria que siempre se ejecuta de la misma forma, en otras palabras, no depende del estado (valores de las variables de instancia) del objeto.

> Las variables y métodos marcadas como static, pertenecen a la clase, en vez de a una instancia particular. De hecho, pueden utilizarse sin tener ninguna instancia de la clase.

Static vs. no static

> Aquello “no static”, pertenecerá al objeto, por lo que usaremos algo como:

class Foo{ Int x = 3; public static void main (String [] args) { Foo f = new Foo(); System.out.println("x is " + f.x); } }

Static vs. no static (II)

> Pero para aquello static usaremos algo como:

class Foo{ static int x = 3; public static void main (String [] args { System.out.println("x is " + Foo.x); System.out.println("x is " + x); } }

Conclusiones sobre Static

> Los métodos estáticos no pueden acceder a variables o métodos no estáticos.

> Los métodos estáticos pueden acceder a métodos y variables estáticos.

> Los métodos estáticos no pueden sobrescribirse. No quiere decir que no puedan ser redefinidos, pero redefinir y sobrescribir no son la misma cosa.

Sobrescribir vs. Ocultar class Foo { public static void classMethod() { System.out.println("classMethod() in Foo"); }

public void instanceMethod() { System.out.println("instanceMethod() in Foo"); } }

class Bar extends Foo { public static void classMethod() { System.out.println("classMethod() in Bar"); }

public void instanceMethod() { System.out.println("instanceMethod() in Bar"); }}

class Test { public static void main(String[] args) { Foo f = new Bar(); f.instanceMethod(); f.classMethod(); } }

> Si ejecutamos esto, la salida será:

instanceMethod() in Bar classMethod() in Foo

Sobrescribir vs. Ocultar (II)

Preguntas