Al cerrar el módulo 1 dejaste BiblioTechApp funcionando, pero con un diagnóstico incómodo: no repite, no decide, no valida y no recuerda nada. Este módulo ataca los tres primeros problemas, y esta lección se ocupa del más urgente: decidir. Hasta ahora tu programa era una línea recta —lee, calcula, imprime— y cualquier "decisión" que tomaba era en realidad un truco aritmético o un operador ternario incrustado en medio de una fórmula. Si un empleado tecleaba -5 días transcurridos, el programa lo aceptaba tan tranquilo. Si el retraso era de 200 días, imprimía la misma frase que si era de 1. Las sentencias condicionales son el mecanismo con el que un programa bifurca su camino: ejecuta unas instrucciones u otras según el estado de los datos. Sin ellas no hay reglas de negocio, no hay validación y no hay software; con ellas, BiblioTechApp empieza a comportarse como una aplicación de verdad.

1. Del programa lineal al programa que decide
2. El if simple
3. El bloque {} y por qué omitirlo es peligroso
4. if-else: las dos ramas
5. La escalera else if
6. Condiciones compuestas y cortocircuito aplicado
7. Anidamiento, cláusulas de guarda y salida anticipada
8. if-else frente al operador ternario
9. Comparar String en condiciones y la trampa de null
10. Las reglas de negocio de BiblioTech como tabla de decisión
11. Validar la entrada del usuario con if
12. Errores Comunes y Consejos
13. Ejercicios

Un programa sin condicionales ejecuta todas sus instrucciones, siempre, en el mismo orden. Eso es lo que hace hoy BiblioTechApp:

Un programa con condicionales tiene caminos alternativos. El mismo recorrido, pero con desvíos:

La diferencia es enorme: el número de recorridos posibles deja de ser uno. Y con ello aparece una responsabilidad nueva que te acompañará el resto del curso: cada rama que escribes es una rama que hay que probar.

La forma más básica ejecuta un bloque solo si una condición booleana es verdadera.

Puntos que hay que interiorizar desde el primer día:

• La condición va siempre entre paréntesis.
• La condición debe ser de tipo boolean. No hay conversión implícita: en Java, if (1) no compila (a diferencia de C o JavaScript). Esto elimina toda una familia de errores.
• Después del ) no se pone punto y coma. if (x > 0); compila, pero el if queda vacío y el bloque siguiente se ejecuta siempre.

Aplicado a BiblioTech:

Observa tres cosas:

1. diasRetraso > 0 produce un boolean; ese es el único requisito.
2. La variable multa está declarada dentro del bloque {}, así que solo existe ahí dentro. Fuera del if no puedes usarla: el compilador dirá cannot find symbol. El ámbito de una variable es el bloque en el que se declara.
3. "Registro completado." se imprime siempre, haya multa o no: está fuera del if.

Java permite que un if gobierne una sola sentencia sin llaves:

Esto compila y funciona. Y es una fuente de bugs tan conocida que la mayoría de las guías de estilo profesionales (Google, Oracle, la de casi cualquier empresa) lo prohíben. El motivo:

La indentación sugiere que las dos líneas dependen del if, pero Java ignora la indentación. Solo la primera sentencia pertenece al if; la segunda se ejecuta siempre, incluso con diasRetraso igual a 0. Este error fue el origen del fallo de seguridad "goto fail" de Apple en 2014, que afectó a millones de dispositivos.

Regla del curso: usa siempre llaves, incluso para una sola línea. El coste son dos caracteres; el beneficio es que añadir una línea más nunca cambiará el significado del código.

Cuando hay una alternativa explícita, else recoge todos los casos en los que la condición es falsa:

if y else son mutuamente excluyentes y exhaustivos: exactamente una de las dos ramas se ejecuta, nunca ninguna y nunca las dos. Esa garantía es muy valiosa: si necesitas que una variable quede inicializada pase lo que pase, un if-else te lo asegura y el compilador lo sabe.

Si quitaras el else, el compilador daría el error variable estado might not have been initialized, porque existiría un camino en el que la variable llegaría sin valor. El compilador de Java analiza los caminos posibles; conviene tenerlo de aliado.

Cuando los casos son más de dos, se encadenan condiciones. Técnicamente no existe una palabra clave elseif: lo que hay es un if dentro del else del anterior, escrito de forma compacta.

Reglas de comportamiento que debes memorizar:

• Las condiciones se evalúan de arriba abajo y se para en la primera verdadera.
• Solo se ejecuta un bloque, aunque varias condiciones sean ciertas.
• El else final es opcional; si no está, es posible que no se ejecute ninguna rama.

Por eso el orden importa. Esta escalera está mal:

Con diasRetraso = 20, la primera condición ya es verdadera y se imprime "Retraso leve". La segunda rama nunca se alcanza con valores mayores que 7. La regla práctica: ordena de la condición más restrictiva a la más general.

En el módulo 1 viste &&, ||, ! y el cortocircuito. Aquí los usas de verdad. Recordatorio en una línea: && evalúa el operando derecho solo si el izquierdo es true; || lo evalúa solo si el izquierdo es false.

Eso convierte el orden de los operandos en una herramienta de protección:

Si escribieras las condiciones al revés (!referencia.isEmpty() && referencia != null), el programa intentaría llamar a un método sobre null y reventaría. Esa protección tiene nombre propio: guarda de nulidad.

El mismo principio aplicado a BiblioTech, donde un préstamo solo se considera "recuperable con aviso" si hay retraso pero aún no se ha llegado al tope:

Y ! para negar, con un consejo: una negación es legible, dos son un acertijo. En lugar de if (!(diasRetraso <= 0)), escribe if (diasRetraso > 0).

Anidar condicionales es meter un if dentro de otro. Funciona, pero degenera rápido en la llamada "flecha de código" (arrow code), en la que la lógica se desplaza a la derecha y se vuelve ilegible:

La técnica que lo arregla se llama cláusula de guarda: en lugar de anidar el caso bueno, se descartan primero los casos malos y se sale. Como en este módulo todo el código vive en main y aún no has visto métodos (llegan en la lección 03-03), la salida se hace con return;, que en main termina el programa.

Compara ambos estilos:

Cuando en el módulo 3 aprendas a escribir métodos, este patrón será todavía más natural: cada guarda hará return del método sin abortar el programa entero. La idea, sin embargo, es la misma y conviene adoptarla ya.

Ya usaste el ternario condicion ? valorSiTrue : valorSiFalse en el módulo 1 para saturar el retraso a cero. Conviene fijar cuándo usar cada herramienta, porque son intercambiables solo en apariencia.

El ternario es una expresión: produce un valor. El if es una sentencia: ejecuta acciones.

El límite práctico está en el anidamiento. Esto es válido pero indefendible en una revisión de código:

La misma lógica con una escalera se lee sin esfuerzo, y es lo que usarás en BiblioTech:

Aquí está el error número uno de quien viene de otros lenguajes. En Java, == sobre objetos compara referencias (si son el mismo objeto en memoria), no contenido. Con String funciona a veces —por el pool de literales que viste en el módulo 1— y falla justo cuando el texto viene del usuario, que es siempre.

Métodos útiles en condiciones:

Para entradas de usuario, equalsIgnoreCase combinado con trim() evita quejas absurdas:

La trampa de null. Si una variable String vale null, llamar a cualquier método sobre ella detiene el programa con un NullPointerException (verás cómo manejarlo en el módulo 6; por ahora, evítalo). La técnica estándar tiene dos formas:

La opción B se conoce como comparación de Yoda. "REF-001" es un literal, jamás es null, y equals devuelve false limpiamente cuando recibe null como argumento. Úsala cuando el valor pueda ser nulo y no quieras escribir la guarda.

Antes de escribir condicionales conviene escribir la tabla de decisión: qué casos existen, cómo se distinguen y qué hace cada uno. Si la tabla está bien, el código sale solo.

Reglas de la biblioteca de Nexus Software (constantes ya fijadas en el módulo 1: DIAS_PRESTAMO = 15, TARIFA_DIARIA = 0.25, MULTA_MAXIMA = 20.0, UMBRAL_LEVE = 7):

Fíjate en que el caso 4 atraviesa los casos 2 y 3: no depende de los días sino del importe. Por eso se comprueba después de calcular la multa, no antes. El flujo completo:

Y la traducción directa a código, sustituyendo los ternarios anidados del módulo 1:

Salida con diasTranscurridos = 120 (105 días de retraso, multa teórica 26,25 €):

Un detalle de diseño que merece la pena señalar: las tres variables estado, gravedad y multa se declaran antes del if y se asignan dentro. Como todas las ramas terminan asignándolas, el compilador acepta usarlas después. Si eliminaras el else final, dejaría de compilar. Es el compilador verificando tu tabla de decisión.

El programa del módulo 1 aceptaba cualquier cosa. Ahora ya puedes rechazar lo que no tiene sentido. La estrategia, con cláusulas de guarda, es leer y comprobar de inmediato:

Recorre lo que acabas de conseguir: el programa ya no acepta días negativos, ni nombres vacíos, ni ISBN de otra biblioteca. Y detente en la limitación evidente: al detectar un error, el programa se rinde y termina. Lo razonable sería volver a pedir el dato. Eso requiere repetir, y repetir es exactamente lo que hacen los bucles de la lección siguiente.

Queda un agujero que no puedes tapar todavía: si el usuario escribe veinte en lugar de 20, Integer.parseInt no falla con un if, sino que detiene el programa con un NumberFormatException. Ninguna condición puede evitarlo, porque el error ocurre dentro de la conversión. Ese hueco lo cierra el módulo 6, con excepciones. Por ahora, asume que el usuario teclea dígitos.

1. El punto y coma fantasma.

Compila sin avisos y es endiabladamente difícil de ver. Ningún IDE moderno lo deja pasar sin subrayar: hazle caso.

2. Confundir = con ==.

Con booleanos compila y produce un bug silencioso. Con otros tipos (if (x = 5)) no compila, porque int no es boolean. Escribe if (disponible) a secas y el problema desaparece.

3. Comparar String con ==. Ya lo has visto: usa equals o equalsIgnoreCase. Siempre.

4. Comparar double con ==. Por la precisión binaria que viste en el módulo 1, 0.1 + 0.2 == 0.3 es false. Para importes, compara con una tolerancia o —mejor— compara los enteros de los que derivan:

5. Escaleras con condiciones solapadas y mal ordenadas. Recuerda: de lo más restrictivo a lo más general. Y verifica que cada rama es alcanzable con algún dato real.

6. Olvidar el else final. Si tus ramas asignan una variable, sin else puede quedar sin asignar. El compilador te avisará; no lo silencies inicializando a un valor falso como "" o -1 sin pensarlo, porque entonces el bug pasa a ejecución.

7. Consejo de estilo: extrae las condiciones complejas a variables booleanas con nombre.

No cuesta rendimiento apreciable y el código se documenta solo. Además, al depurar (lección 02-05) verás cada condición por separado.

8. Consejo: prueba los límites. Si tu condición es diasRetraso <= UMBRAL_LEVE, prueba con 6, 7 y 8. Los bugs de condicionales viven casi siempre en el borde exacto.

Escribe un programa que, dadas las variables titulo, disponible (boolean) y diasRestantes (int, días que faltan para que venza el préstamo en curso; vale 0 si el libro está en la estantería), imprima uno de estos mensajes:

• Si disponible es true: "Java Efectivo: DISPONIBLE para prestamo inmediato".
• Si no está disponible y diasRestantes es mayor que 0: "Java Efectivo: PRESTADO, vuelve en N dias".
• Si no está disponible y diasRestantes es 0 o negativo: "Java Efectivo: PRESTADO Y VENCIDO, reclamar al empleado".

Usa una escalera else if y llaves siempre. Prueba con los tres casos.

Un empleado quiere llevarse un libro. La biblioteca de Nexus Software solo autoriza el préstamo si se cumple todo lo siguiente:

• El nombre del empleado no está en blanco.
• El libro está disponible (disponible == true).
• El empleado no tiene multas pendientes (multaPendiente == 0.0).
• El número de préstamos activos del empleado (prestamosActivos) es menor que 3.

Escribe el programa con cláusulas de guarda: cada incumplimiento imprime en System.err un mensaje específico y termina con return. Si todo se cumple, imprime la autorización con la fecha de devolución expresada como "Devolver en 15 dias" usando la constante DIAS_PRESTAMO.

Pruébalo con Nuria Vidal, disponible true, multa 0.0 y 1 préstamo activo (debe autorizar), y con Diego Alonso, disponible true, multa 4.50 y 0 préstamos (debe rechazar).

Dadas dos variables String referencia y String referenciaBuscada, cualquiera de las cuales puede valer null, escribe la lógica que imprima:

• "COINCIDE" si ambas tienen el mismo contenido ignorando mayúsculas.
• "SIN REFERENCIA" si alguna de las dos es null o está en blanco.
• "NO COINCIDE" en cualquier otro caso.

El programa no puede detenerse con un NullPointerException en ninguna combinación posible. Prueba, como mínimo, estas cuatro: ("REF-001", "ref-001"), ("REF-001", "REF-002"), (null, "REF-001"), ("REF-001", null).

Solución 1

Salida con los valores del ejemplo: Java Efectivo: PRESTADO, vuelve en 4 dias.

Prueba los otros dos casos cambiando disponible a true y, después, dejando disponible = false con diasRestantes = 0. Observa que no hace falta escribir else if (!disponible && diasRestantes > 0): al estar en el else, ya sabemos que disponible es false. Repetir la condición sería ruido.

Solución 2

Salida con Nuria Vidal:

Con empleado = "Diego Alonso" y multaPendiente = 4.50, la tercera guarda dispara y el programa imprime en System.err:

Lo importante del ejercicio: cuatro condiciones y cero anidamiento. Cada guarda es independiente, tiene su mensaje propio y puede añadirse o quitarse sin tocar las demás.

Solución 3

Resultados de las cuatro combinaciones pedidas:

Claves de la solución:

1. La condición compuesta se extrae a faltaAlguna, un booleano con nombre. Se lee mejor y, al depurar, podrás inspeccionar su valor de un vistazo.
2. El orden dentro de cada || es crítico: referencia == null va antes que referencia.isBlank(). Si los intercambiaras, el programa reventaría con null.
3. Cuando se llega al else if, ambas variables están garantizadas no nulas, así que equalsIgnoreCase es seguro. Si la escalera estuviera al revés, no lo sería.

Tu programa ya decide. Has visto el if simple y por qué las llaves nunca deben omitirse; el if-else y la garantía de exhaustividad que le da al compilador; la escalera else if, en la que el orden de las condiciones es la lógica; las condiciones compuestas con cortocircuito usadas como guardas de nulidad; las cláusulas de guarda como antídoto contra el anidamiento; el reparto de papeles entre el ternario (elegir un valor) y el if-else (ejecutar acciones); la comparación correcta de String con equals y equalsIgnoreCase, incluida la comparación de Yoda para sobrevivir a null; y, sobre todo, el hábito de escribir primero la tabla de decisión y después el código, que es lo que ha convertido las cuatro reglas de negocio de BiblioTech en una escalera limpia y verificable.

BiblioTechApp clasifica correctamente los cuatro casos de multa, avisa cuando se alcanza el tope y rechaza las entradas absurdas. Pero se rinde a la primera: cuando detecta un dato inválido, termina en lugar de volver a preguntar, y sigue procesando una sola devolución por ejecución.

En la siguiente lección, Bucles, romperás esa barrera. Con while, do-while y for tu programa podrá repetir un bloque tantas veces como haga falta: reintentar la lectura hasta que el dato sea válido, recorrer todo el catálogo de la biblioteca y acumular las multas de una tanda entera de devoluciones sin duplicar una sola línea de código.