1.- ¿Qué hace (y para qué sirve) exactamente un método estático?
2.- ¿Por qué un método estático no puede ser abstracto? (de ahí que las interfaces no puedan tener métodos estáticos).
3.- Al igual que un método estático únicamente puede modificar un atributo estático, ¿un método no-estático únicamente puede modificar un atributo no-estático?
4.- ¿Por qué una interfaz solo puede tener atributos estáticos o finales (constantes)?
Gracias, seguiré estudiando :silbar:
Un método estático es también llamado "método de clase"
Los métodos estáticos no necesitan de un objeto para ser utilizado, y por esta razón tu puedes acceder a este método utilizando el nombre de la clase:
Clase.metodoEstatico();
Un método estático solo puede modificar atributos estáticos ya que de alguna manera ambos no pertenecen al objeto (si creas 10 objetos con un atributo estático, los 10 objetos tendrán el mismo valor en aquel atributo, si cambias ese valor en uno de los objetos, se cambiara en todos)
En otras palabras, las variables de clase solo pueden ser modificadas por métodos de clase, de hecho, tu no deberías poder usar la palabra this. para acceder a una variable estática.
En respuesta a tu pregunta 3 es muy deducible el porque. La razón por la cual no puedes crear un método estático y abstracto es porque los métodos estáticos se utilizan sin necesidad de un objeto, y si no creas un objeto de una clase abstracta nunca podrás definir sus métodos estáticos, por lo tanto es imposible el utilizar un método estático y abstracto, ya que simplemente no esta definido. (espero me entiendas)
Respecto a tu ultima pregunta, solo puedo decir que todo en una interface es publico, y por esa razón es recomendable que si declaras algún atributo tiene que ser por recomendación final (regla de encapsulamiento). Si un atributo es publico, sera accesible desde cualquier lugar, por lo tanto lo mejor de todo es que esta variable sea FINAL de esta manera no tendrás problemas en que cambien el valor desde cualquier otro lugar. Pero según se no es obligatorio el que sea estático o final.
Modifico, efectivamente tienes razón tiene que ser public estatico y final... la verdad no sabría que decirte, pero según se las interfaces se utilizan siempre para redefinir métodos (no he tenido necesidad de utilizar variables)
1) Un método estático solo puede manejar datos estáticos porque un método estático existe desde que el ClassLoader carga su clase. Una variable no estática está asociada con la existencia de un objeto. Por lo tanto, si los métodos estáticos "siempre están allí", ¿como pueden tener referencias de objetos (al cargarse la clase por medio del ClassLoader al levantar la aplicación) que aún no existen?
2) abstract quiere decir: "No implementa funcionalidad" y static dice "Aquí hay funcionalidad todo el tiempo sin necesidad de un objeto". Por lo que si haces un método static abstract también, no tendría sentido. Se contradice.
3) No. Un método no estático puede manipular datos estáticos sin problemas.
4) Los atributos de una interfaz son public, static y final porque una interfaz no puede ser instanciada directamente. El valor de su variable debe ser asignado en un contexto estático en caso no existan instancias que sobre-escriban la variable, por ésta razón también son constantes, porque se asegura que tengan algún valor en caso que ninguna implementación la sobre-escriba.
Mucho mejor.
Thx.
Sigo aquí con las dudas.
Dado el siguiente código:
(http://nsae02.casimages.net/img/2015/02/04/mini_150204010945543233.png) (http://www.casimages.es/i/150204010945543233.png.html)
(a): incorrecto.
(b): correcto.
(c): correcto.
(d): correcto.
¿Estaría bien?
De donde sacas eso :huh:
Las alternativas B y D supongo son correctas.
Ya en la alternativa C ya se esta implementado L2 gracias a la clase D entonces no le veo el caso de reimplementar.
Y bueno la A no porque estas heredando una interfaz. /* No tomen en cuenta esto, se me fue la cabeza :rolleyes: :silbar:*/
Cita de: Nac-ho en 4 Febrero 2015, 13:25 PM
Ya en la alternativa C ya se esta implementado L2 gracias a la clase D entonces no le veo el caso de reimplementar.
Aún así, creo que sería correcto que Y vuelva a implementar la interfaz I2 (haciendo sobreescritura de métodos, por ejemplo).
Cita de: Nac-ho en 4 Febrero 2015, 13:25 PM
Y bueno la A no porque estas heredando una interfaz.
No te entiendo. La clase W es una subclase de la clase A y de la clase B (aquí no hay interfaces). La respuesta de porqué es incorrecto, creo que es porque en Java está prohibido la herencia múltiple, es decir, una subclase no puede tener dos superclases.
Sry. Lei mal, tienes razon, es incorrecto porque no puede haber multi herencia (lo lamento estaba en otra ;D) :-X (que vergüenza, lo lamento en serio)
Y si, pero no es necesario reimplementar, solo basta con redefinir los métodos. De hecho supongo que si reimplementas y no redefines los métodos aun asi no te molestara (ya que fueron definidos por la super clase) por eso no le veo el caso al implements (no te digo que no funcione, funcionara y no te dará error, pero no le veo la utilidad) quizás haga mas entendible el código ?? :huh:
A) Java no soporta herencia múltiple, por lo tanto, no es una opción válida.
B) La clase C ya implementa L1, por lo que las subclases de C también heredan la implementación.
C) Lo mismo. Lo válido sería Y extends D implements L1. (L2 ya fue implementado por D).
D) Z implementa L1 y L2. Ésta es la opción más coherente.
Pero aunque ya lo implemente, el código sería correcto, no?
Si seria correcto, pero aun así no es necesario.
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.
Sí, es un poco absurdo la verdad.
Ahí va otra:
He visto cosas del tipo ob = new A();
En ese caso, ¿cuál sería el tipo estático del objeto? :huh:
te refieres a que nunca se declaro ob?
A ob; // Declaracion
ob = new A(); // Inicializacion
¿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).
L1 -> Interface
A implements L1
B implements L1
C implements L1
Puedes hacer:
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:
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:
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:
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.
Gracias. Otra:
Me pone en una pregunta: "¿Por qué podemos hacer lo siguiente en Java, sea cual sea el tipo de la variable a?"
System.out.println(a);
Sobrecarga.
println es un método con sobre carga (dependiendo de sus entradas cambia su funcionamiento)
CitarPrintStream.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 (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:
NewClass objeto = new NewClass();
System.out.println(objeto.toString());
System.out.println(objeto);net.elhacker.controller.NewClass@15db9742
net.elhacker.controller.NewClass@15db9742PD: No reutilices tanto el tema :o / pensándolo mejor teniendo en cuenta el titulo no creo que importe el que lo reutilices ya que concuerda con el tema tratado xD!.
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?
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.