Java sin Boilerplate, no es Java.

La POO es un paradigma que permite hacer de la programación un arte, pero pienso que hay ciertos lenguajes que acaban con la creatividad por el hecho de tener que enfocarse en estructuras de código repetitivo, eso me pasó cuando me tocó aprender Java. Me tomé mi tiempo para escribir este post, porque estoy seguro que Java es un lenguaje amado por muchos programadores, se han hecho increíbles desarrollos con este lenguaje y se siguen haciendo, por ello, no solo voy a explicar mi punto de vista, sino también la opinión de programadores expertos en Java.

Empecemos por definir ¿qué es boilerplate?, (1) bueno en simples palabras una cita de Spring in Action:
“¿Alguna vez has escrito algún código y luego sentiste que ya habías escrito el mismo código antes? Eso no es déjà vu, mi amigo. Eso es el código repetitivo, el código que a menudo se tiene que escribir una y otra vez para llevar a cabo tareas comunes y simples.”

Boilerplate, ¿es bueno o malo?, este punto es muy debatido; encontré muy buenas posturas tanto a favor como en contra (2):

• La duplicación lógica tiende a ser mala. Pero la duplicación de código, que no es una duplicación lógica (reglas comerciales, etc.), no lo es.
• Honestamente, no puedo ver cómo alguien puede preferir el código que es más detallado y propenso a errores que el código que es más conciso, claro y con menos errores.
• Si se requiere esfuerzo para leer el código, entonces no está listo y necesita ser refactorizado. El buen código es tan obvio de leer como sea posible.

En mi humilde opinión, todo llevado al extremo es malo, boilerplate nos puede ser muy útil por ejemplo en plantillas, dado que es un código probado y testeado, no es necesario tener que reinventar la rueda, así también para los desarrolladores front esta metodología es muy útil.

Las cosas cambian, cuando el lenguaje te obliga a tener que escribir una y otra vez la misma estructura de código. En una presentación de Trisha Gee (experta programadora Java), habló sobre el boilerplate de Java y cómo esto afecta a los programadores que migran a otros lenguajes modernos, al punto de considerar terriblemente hermoso a Kotlin.
Estos son algunos puntos que expuso, sin antes recomendarles que vean su presentación (3):

Java tiene abundante boilerplate:

1. Casting

   void createSegment(Object obj){
       if (obj instanceof View){
           ((View) obj).initialise();
       }
   }
   

   ¿Por qué tengo que declarar View si en el if indico que estoy trabajando con View?

2. Nulls

   void validateCustomer(Optional<CustomerOptional> customer){
       customer.flatMap(CustomerOptional::getName)
               .filter(name -> name.startsWith(“A”))
               .ifPresent(s -> throwSecurityException(“Names are not allowed to begin with A”))
   }
   

   De nuevo el mismo caso, tengo que pasar un argumento CustomerOptional dentro de una función de la clase CustomerOptional.

3. Switch

   int port = Integer.valueOf(portInputValue);
   PortType type = PortType.UNKNOWN;
   switch (port){
       case 20:
           type = PortType.FTP;
           break;
       case 80:
           type = PortType.HTTP;
           break;
       case 8080:
           type = PortType.HTTP;
           break;
       case 27017:
           type = PortType.DATABASE;
           break;
       default:
           if(port >= 20001 && port <= 30000){
               type = PortType.SAFE;
           } else if(port >= 9080 && port <= 9092){
               type = portType.BUSY;
           }
   }
   

   Esto ya es crítico, no se puede indicar un rango en los case, por ello tengo que declarar un if … else … en el default.

4. Default Parameter Values

   void printMessage(String message){
       printMessage(message, “”, “”);
   }
   void printMessage(String message, String prefix){
       printMessage(prefix, message, “”);
   }
   void printMessage(String message, String prefix, String suffix){
       System.out.format(“%s %s %s”, message, prefix, suffix);
   }
   

   Encuentra el bug. Al no tener valores por defecto en los parámetros, es más propenso a errores.

5. Ranges

   IntStream numbers = IntStream.range(1, 100);
   

   Para versiones < Java10.

6. Lambda Expressions

   button.addActionListener(event -> System.out.println(“I was pushed, I didn’t fall!”))
   

   ¿Es necesario escribir “event” a algo obvio?

Soy programador en python, y los puntos antes mencionados son evidentemente absurdos, y eso que me faltó los getters y setters.

Para solucionar el problema de código redundante, han propuesto algunas soluciones como Project Lombok, un proyecto interesante, tiene disponible librerías instalables para IDE’s; lo malo, te hace dependiente de una herramienta para hacer código limpio, y por ello no puedo evitar compararlo con python, un lenguaje eficiente que se puede escribir desde la terminal sin ningún problema.

En conclusión, Java es un lenguaje que abusa del boilerplate, pero lo que en verdad me preocupa es cuánto puede afectar eso a un programador. Un punto de enfoque puede ser la eficiencia, cuanto más verbose code sea, más propenso a errores será; otro enfoque es el paradigma de programación utilizado, los cambios constantes de la tecnología que hacen que las tareas repetitivas se automaticen y el tener que manejar cada vez más cantidades de datos, tal vez sea una señal de que tenemos que cambiar el paradigma POO.

Por ahora lo dejo ahí, este es mi punto de vista con la que busco aportar a la comunidad, y si alguien pregunta si volveré a programar en Java, mi respuesta es: si, algún día. Cada vez son más constantes las actualizaciones que cuando llegue a la versión one hundred puede que me anime.

(1)What is boilerplate code?
(2)Code boilerplate: Is it always bad?
(3)Is Boilerplate Code Really So Bad?