Aclaración de conceptos teóricos

[3n31ch]

Si seria correcto, pero aun así no es necesario.

[Usuario Invitado]

Si A implementa a L1 y X hereda de A e implementa también a L1, no habrá error para el compilador, pero es redundante. Haz la prueba y verás que X aunque implementa a L1 igual que su superclase no necesitas sobre-escribir los métodos de L1. ¿Por qué? Pues porque ya lo hiciste en la superclase A.

Si haces eso no tendría lógica alguna. Prueba antes de preguntar, y alguna duda la comentas.

[JonaLamper]

Sí, es un poco absurdo la verdad.

Ahí va otra:

He visto cosas del tipo

Código (java) [Seleccionar] Expandir

ob = new A();

En ese caso, ¿cuál sería el tipo estático del objeto? 

[3n31ch]

te refieres a que nunca se declaro ob?

Código (java) [Seleccionar] Expandir

A ob; // Declaracion
ob = new A(); // Inicializacion

[Usuario Invitado]

¿A qué te refieres con tipo estático?

A al implementar L1 es de tipo L1. Por lo que al seguir la programación orientada a interfaces puedes hacer polimorfismo (como si se tratara de herencia).

Código [Seleccionar] Expandir

L1 -> Interface
A implements L1
B implements L1
C implements L1

Puedes hacer:

Código (java) [Seleccionar] Expandir

L1 obj = new A();
obj = new B();
obj = new C();

Una interface es un contrato. Ésta especifica qué es lo que debe hacer pero no cómo la clase que lo implemente. Por ejemplo:

Código (java) [Seleccionar] Expandir

public interface Construccion {

    void hacerBases();
    void hacerColumnas();
    void hacerTechos();

}

Nos dice que toda construcción debe tener esas 3 tareas pero que cada construcción las puede hacer a su manera.

Por ésto, podemos hacer:

Código (java) [Seleccionar] Expandir

public class Casa implements Construccion {
    // sobre-escribe métodos
}
public class Edificio implements Construccion {
    // sobre-escribe métodos
}

Con la ayuda de las interfaces generas independencia y ganas mucha flexibilidad además de simular multiherencia.

Como dato adicional, a partie de Java 8 puedes especificar la implementación de un método en la misma interface:

Código (=java) [Seleccionar] Expandir

public interface Construccion {

    default void hacerBases() {
        System.out.println("Haciendo bases...");
    }

}

Recuerda que los métodos en una interface son public y abstract por defecto, por lo que no es necesario especificar public.


Salu2.

[JonaLamper]

Gracias. Otra:

Me pone en una pregunta: "¿Por qué podemos hacer lo siguiente en Java, sea cual sea el tipo de la variable a?"

Código (java) [Seleccionar] Expandir

System.out.println(a);

[ivancea96]

Sobrecarga.

[3n31ch]

println es un método con sobre carga (dependiendo de sus entradas cambia su funcionamiento)

PrintStream.println(), PrintStream.println(boolean), PrintStream.println(char), PrintStream.println(char[]), PrintStream.println(double), PrintStream.println(float), PrintStream.println(int), PrintStream.println(long), PrintStream.println(java.lang.Object), PrintStream.println(java.lang.String)

Ve la api: http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#out

Por si acaso, cada clase que creas hereda de Object (aun cunado no lo indiques) por esta razón todas las clases tienen el método toString() el cual utiliza System.out.println() para imprimir un objeto.

Cuando imprimes un objeto se imprime su método toString(). puedes ver que ambas salidas son iguales en el siguiente código:

Código (java) [Seleccionar] Expandir

NewClass objeto = new NewClass();
System.out.println(objeto.toString());
System.out.println(objeto);

Código [Seleccionar] Expandir

net.elhacker.controller.NewClass@15db9742
net.elhacker.controller.NewClass@15db9742

PD: No reutilices tanto el tema   / pensándolo mejor teniendo en cuenta el titulo no creo que  importe el que lo reutilices ya que concuerda con el tema tratado xD!.

[JonaLamper]

Hay otra que dice: "Indica por qué en un programa orientado a objetos, el forzar la conversión de clases (casting) no es recomendable. Razona tu respuesta."

¿Alguna idea? Sé lo que es hacer casting pero... ¿Por qué no es recomendable?

[Usuario Invitado]

Siempre vas a necesitar hacer castings explícitamente (implícitamente también ocurre con los llamados upcasting y downcasting).

Respecto a por qué no es recomendado, pues es porque cuando fuerzas a que un objeto se convierta a otro en tiempo de ejecución a un % de probabilidades que no se pueda realizar, quizás porque X método no ha devuelto el valor que se esperaba y no se ha podido hacer un castings, por lo que tendrías una ClassCastException.

Siempre es recomendable trabajar con datos específicos, pero en algunas ocasiones no podrás, por ejemplo con métodos que devuelvan Object. Allí siempre vas a verte obligado a hacer un cast, cosa que tampoco es malo. Si se requiere se debe usar sin más.