De programación procedural a POO
Antes en el curso les conté sobre los beneficios de la Programación Orientada a Objetos (POO). Ahora, durante las próximas lecciones, vamos a ver esos beneficios en acción.
Para lograrlo, vamos a empezar escribiendo un programa con un enfoque procedural (también llamado procedimental). Este fue el paradigma más común antes de la POO y está basado en procedimientos, es decir, en llamadas a funciones o métodos que operan sobre un conjunto de variables.
La idea es la siguiente: primero escribimos el programa en estilo procedural, identificamos sus problemas, y luego lo vamos refactorizando paso a paso hasta convertirlo en un diseño orientado a objetos. Así vas a notar por qué POO no es solo “usar clases porque Java las tiene”, sino una forma distinta de pensar y organizar el código.
Un ejemplo procedural: calcular el salario de un empleado
Supongamos que queremos escribir un programa para calcular el salario de nuestros empleados. Empezamos declarando tres variables:
salarioBasehoraExtratasaHoraria
Para simplificar, las declararemos como enteros (así no nos preocupamos todavía por el tipo de dato óptimo):
public class Main {
public static void main(String[] args) {
int salarioBase = 50_000;
int horaExtra = 10;
int tasaHoraria = 20;
}
}Hasta aquí todo es sencillo: solo tenemos datos sueltos.
Un método para calcular el salario
Ahora implementemos un método que reciba estos datos y devuelva el salario total.
Como el método main es static, por ahora también vamos a declarar este método como static para poder llamarlo fácilmente desde main. (Más adelante veremos con calma qué significa realmente static y por qué importa).
public class Main {
public static void main(String[] args) {
int salarioBase = 50_000;
int horaExtra = 10;
int tasaHoraria = 20;
}
public static int salario(
int salarioBase,
int horaExtra,
int tasaHoraria
) {
return(salarioBase + (horaExtra * tasaHoraria));
}
}Dentro del método, el cálculo es directo: salario base más horas extra multiplicadas por la tasa horaria.
Llamar al método desde main
Volvemos a main, llamamos el método, guardamos el resultado en una variable y lo imprimimos:
public class Main {
public static void main(String[] args) {
int salarioBase = 50_000;
int horaExtra = 10;
int tasaHoraria = 20;
int total = salario(salarioBase, horaExtra, tasaHoraria);
System.out.println(total);
}
public static int salario(
int salarioBase,
int horaExtra,
int tasaHoraria
) {
return(salarioBase + (horaExtra * tasaHoraria));
}
}Si lo ejecutamos, obtenemos:
50200
Todo bien… por ahora.
Entonces, ¿qué tiene de malo este código?
Técnicamente, nada. En un programa pequeño, esto funciona.
El problema aparece cuando el programa crece. Si le agregamos más cálculos, más reglas, más datos y más lógica, el método main empieza a llenarse de líneas y se vuelve un bloque enorme y difícil de leer.
Podemos extraer partes a métodos (como hicimos con salario), pero aun así seguimos con el mismo estilo: un montón de variables sueltas y métodos que operan sobre ellas. Eso es programación procedural.
“Pero… ¿no estoy usando Java? ¿Eso no es POO automáticamente?”
Aquí viene algo importante: he visto a muchos desarrolladores escribir código así en Java y pensar que están haciendo POO solo porque están usando un lenguaje orientado a objetos.
Pero no: usar clases en Java no significa que estés programando orientado a objetos.
La POO no se trata solo de “meter código dentro de una clase”. La POO se trata de aplicar técnicas específicas para organizar el código de una manera más robusta: separar responsabilidades, encapsular datos, reducir dependencias y hacer el diseño más reutilizable y mantenible.
Y eso es exactamente lo que vamos a aprender en el resto de esta sección.
Un síntoma claro del estilo procedural: demasiados parámetros
Observa el método salario:
public static int salario(int salarioBase, int horaExtra, int tasaHoraria)Aquí tenemos solo tres parámetros, y no se ve tan mal. Pero en la vida real es muy común terminar con métodos que tienen 5, 10 o incluso más parámetros.
Cuando constantemente estás llamando métodos y pasando una lista larga de argumentos, suele ser una señal de que el diseño está quedando en estilo procedural.
En un diseño orientado a objetos, en lugar de pasar tantos datos sueltos, esos datos suelen vivir dentro de un objeto que representa una entidad del dominio (por ejemplo, un Empleado).
Problemas típicos del código procedural cuando crece
Cuando se programa así y el proyecto se vuelve grande, aparecen problemas comunes:
La primera dificultad es el mantenimiento. Si algo falla, tienes que revisar varias partes del código para entender qué cambiar. Y cuando cambias algo, es fácil que otras partes se rompan.
El segundo problema es la falta de reutilización. Terminas con muchas funciones dispersas y para reutilizarlas en otro proyecto te toca copiar y pegar, y luego adaptarlas porque los parámetros y dependencias no coinciden.
Y finalmente aparece el famoso “código espagueti”: todo se conecta con todo, los cambios se vuelven peligrosos, y el diseño se vuelve difícil de extender.
Lo que sigue: refactorizar hacia POO
En las próximas lecciones vamos a refactorizar este código. Refactorizar significa cambiar la estructura interna del programa sin cambiar lo que hace, pero haciendo que quede mejor diseñado.
Vamos a transformar este ejemplo procedural en un diseño orientado a objetos, y ahí vas a ver los beneficios en acción.
Nos vemos en la siguiente lección.