El problema de la enseñanza de Java

Durante muchos años Java se enseñó muchas veces desde la herramienta y no desde los conceptos.

Un estudiante podía aprender:

• Applets.
• Swing.
• JSP.
• Servlets.
• JDBC.

En mi caso particular, el primer acercamiento a Java fue mediante un applet. La enseñanza se enfocaba en ver que Java podía ejecutarse dentro de una aplicación gráfica o un navegador, pero no necesariamente en comprender conceptos más amplios como diseño orientado a objetos, separación de responsabilidades o arquitectura de aplicaciones.

Porque un applet por sí solo no explica:

Clase
  |
Objeto
  |
Responsabilidad
  |
Colaboración entre objetos
  |
Sistema completo

Un alumno podía entender cómo crear un Applet y sobrescribir un método como paint(), pero eso no necesariamente lo preparaba para diseñar una aplicación empresarial.

En mi caso no llegaba a comprender:

• programación orientada a objetos;
• responsabilidades de una clase;
• separación de capas;
• arquitectura cliente-servidor;
• persistencia;
• diseño de aplicaciones.

Por ejemplo, una aplicación podía comenzar con una estructura como esta:

JSP
 |
 ├── HTML
 ├── Java
 ├── SQL
 └── lógica del negocio

Esta forma de desarrollo permitía crear aplicaciones funcionales, pero al crecer el sistema aparecían problemas de mantenimiento y organización.

El siguiente paso era comprender una arquitectura más ordenada:

Vista
 |
 ▼
Controlador
 |
 ▼
Servicio
 |
 ▼
Repositorio
 |
 ▼
Base de datos

Ahí la programación orientada a objetos comenzaba a tomar más sentido, porque las clases dejaban de ser solamente agrupaciones de código y pasaban a representar responsabilidades dentro del sistema.

El exceso de herramientas

Otro problema fue que muchas veces se aprendían frameworks antes de comprender las bases.

Un alumno podía aprender:

@GetMapping("/productos")

pero no necesariamente entender que detrás existía un flujo HTTP que históricamente se resolvía mediante Servlets.

Comprender primero:

HTTP Request
      |
      ▼
Servlet
      |
      ▼
Código Java
      |
      ▼
HTTP Response

permite entender mejor qué problemas solucionan frameworks posteriores.

La importancia de las capas

Una aplicación real no es solamente una pantalla. Tiene diferentes responsabilidades:

Usuario
  |
Vista
  |
Controlador
  |
Servicio
  |
Datos
  |
Base de datos

Cuando se entienden estas capas, tecnologías como Spring Boot, Jakarta EE u otros frameworks dejan de ser cajas negras y pasan a ser herramientas que automatizan soluciones conocidas.

Conclusión

Java no es difícil solamente por su sintaxis. Muchas veces la dificultad está en aprender conceptos de programación y arquitectura al mismo tiempo que se aprende el lenguaje.

Una enseñanza progresiva debería avanzar desde:

1. POO.
2. Modelado de objetos.
3. Separación de responsabilidades.
4. Persistencia.
5. Aplicaciones web.
6. Frameworks.

Primero entender las piezas; después utilizar herramientas que automaticen esas piezas.