Mensajes

[comprensión]

No es buena idea generalizar, siempre hay excepciones.

Como dice @engelx, es de acuerdo a cómo tu te sientes más comodo aprendiendo. Conozco gente que no le gusta nada leer, y aprende mejor con multimedia (audio, videos, etc). Todo es de acuerdo a cómo captas mejor la información.

Pero aunque haya vídeotutos muy buenos (acudo de vez en cuando para aprender o dudas sobre Spring MVC), un programador debería de desarrollar su capacidad lectora, a esto me refiero por comprensión. Muchísimo material hay para leer, y muy bueno, asi que deberías aprovecharlo.

Para resumir, aprende de ambas formas. Ninguna te prohíbe la otra.

Salu2.

@Invisible, lo que me causó gracia es que digas que Spring Framework, uno de los mejores frameworks para desarrollo están "pasados de moda". C#, Java, PHP, etc son lenguajes en continua evolución. Solo hace falta echar un vistazo hace unos años y uno se da cuenta cuánto han evolucionado.

Pero mejor me quedo callado, para no entrar en polémicas

Salu2.

Es raro que no funcione el salto de línea en enter (Quizás es porque está en un form y el "enter" llama al botón submit). Me parece algo tonto que no sea posible. No he probado 3.5 pero con PrimeFaces 4+ nunca he tenido problemas de ese tipo.

[upcasting]

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.

Creo que así te conectas a una BBDD Oracle (que me corrijan los entendidos de PHP)

Código (php) [Seleccionar] Expandir

$connection = oci_connect("username","pass", "123.123.123.123:1521/bbdd");
    // hacer cosas...

[tipo]

¿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.

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.

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.

Si sabes C# te será sencillo aprender Java. Uno de los mejores libros en español es Como programar en Java de Deitel & Deitel. Es un libro muy extenso que abarca gran cantidad de temas. Empieza desde lo básico hasta llegar a temas de GUI y Web (éste último un poco básico).

Lo que más me agrada del libro es que tiene una gran cantidad de ejemplos y ejercicios y talleres al final de cada capítulo, lo que lo hace más aprovechable.

Si el inglés no es tu problema, te recomiendo Effective Java de Joshua Bloch. Es un libro 100% recomendado. Te hará mucho mejor programador Java.

Yendo un poco más profundo, hacia el tema Web, te recomiendo el libro de Cecilio Álvarez, Arquitectura Java sólida. Éste libro es una muy buena introducción hacia Java EE y es gratuito. En el libro aprendes a usar JSPs, Servlets, patrones de diseño y principios de desarrollo de software. También verás la API de persistencia JPA y su implementación más famosa Hibernate y frameworks MVC como JSF y Spring MVC.

Nunca pierdas tu instinto autodidacta. Investiga, prueba, descrubre y aprende.

Salu2.

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.