La lección anterior terminó con un diagnóstico: el dominio de BiblioTech ya no se puede corromper desde fuera, pero la superficie pública de sus clases ha crecido sin control. Prestamo expone más de veinte métodos, entre ellos un getEmpleadoNoUsar() cuyo propio nombre confiesa que no debería existir. Encapsular responde a la pregunta cómo oculto lo que hay dentro; queda por responder la más difícil: qué merece estar fuera. Ese es el territorio de la abstracción, el cuarto pilar de la POO y, a diferencia de los otros tres, no un mecanismo del lenguaje sino una disciplina de diseño: quedarse con lo esencial para el problema que se resuelve y descartar todo lo demás. Un mapa de metro es una abstracción magistral —miente sobre las distancias, ignora la geografía y sin embargo te lleva a tu destino mejor que un plano a escala—. Esta lección te enseña a diseñar así: a decidir qué expones, a no mezclar niveles dentro de un método, a documentar contratos y a reconocer tanto las abstracciones que gotean como el vicio contrario, abstraer lo que nadie ha pedido.

1. La abstracción como disciplina de diseño
2. Abstracción frente a encapsulamiento
3. Niveles de abstracción y por qué no deben mezclarse
4. Refactorización: separar la regla de la presentación
5. Diseño por contrato: precondiciones, postcondiciones e invariantes
6. El vocabulario del dominio
7. Separar el qué del cómo
8. API pública mínima y el coste de exponer de más
9. Abstracciones con fugas
10. Sobreabstracción y YAGNI
11. Los mecanismos que faltan: interfaces y clases abstractas
12. Errores Comunes y Consejos
13. Ejercicios

Abstraer es quedarse con lo esencial y descartar lo accidental. La palabra clave es "para el problema": no existe la abstracción correcta en absoluto, solo la correcta para un propósito.

El mismo libro físico se abstrae de forma distinta según quién lo modele:

Ninguna es más "verdadera" que otra. Un Libro en BiblioTech no tiene peso porque a BiblioTech no le importa el peso, y añadirlo "por si acaso" sería contaminar el modelo.

De ahí la primera pregunta que debes hacerte ante cualquier clase:

¿Qué necesita saber y hacer este objeto para el problema que resolvemos? Todo lo demás sobra.

Los dos conceptos se confunden constantemente porque colaboran, pero responden a preguntas distintas:

Se puede tener una sin la otra, y ambos fallos son reales:

• Buen encapsulamiento, mala abstracción: todos los campos private, pero con treinta getters y setters validados. Nada se corrompe, pero la clase no significa nada; es una hoja de cálculo con sintaxis Java.
• Buena abstracción, mal encapsulamiento: una API pública magnífica —prestar(), devolver(), calcularMulta()— junto a campos public que permiten saltársela. El diseño es correcto y no se cumple.

Necesitas las dos. La abstracción decide qué puertas hay; el encapsulamiento garantiza que no hay otras.

Un programa tiene capas de detalle, del concepto al bit:

La regla, conocida como principio de nivel único de abstracción:

Dentro de un mismo método, todas las sentencias deberían pertenecer aproximadamente al mismo nivel.

¿Por qué? Porque leer un método que salta de nivel obliga a cambiar de marco mental en cada línea. Un método que dice "registra la devolución, y por cierto aquí va la fórmula del IVA y el ancho de columna del recibo" no se puede leer en diagonal: hay que leerlo entero, cada vez.

Este es el aspecto de la mezcla, y probablemente reconozcas el estilo porque es exactamente el de tu main del módulo 2:

Los problemas concretos, más allá de la estética:

1. No se puede reutilizar la regla. Si otro punto del programa necesita la multa, tiene que copiar la fórmula o llamar a este método y aguantar el recibo por consola.
2. No se puede probar. Para verificar el cálculo hay que capturar la salida estándar (módulo 11).
3. No se puede cambiar el canal. Si mañana el recibo es una página web o un PDF, hay que reescribir la lógica de negocio junto con el formato.
4. El tope de 20 € está duplicado. Ya vive en Material.MULTA_MAXIMA, y aquí aparece como literal. Dos verdades para un mismo hecho.
5. Viola la Ley de Demeter tres veces con prestamo.getMaterial().getX().

Reescribamos el método anterior repartiendo cada línea a su nivel.

Nivel 3, reglas de negocio: ya están en el dominio. Prestamo.registrarDevolucion(int) calcula la multa, marca el préstamo, libera el material y descuenta al empleado (lección 03-07). No hay que escribir nada nuevo.

Nivel 1, presentación: una clase aparte, fuera del dominio.

Nivel 4, el caso de uso: coordina, no calcula ni imprime.

Dos líneas. Y cada una a su nivel.

Compara el antes y el después:

Nota el paquete nuevo, presentacion. La estructura de BiblioTech empieza a reflejar sus niveles de abstracción:

Esta separación es la semilla de la arquitectura por capas que verás completa en el módulo 12.

Una abstracción es una promesa: "llámame así y te devolveré esto". Cuanto más explícita sea la promesa, menos margen hay para malentendidos. El diseño por contrato formaliza esa promesa en tres partes:

En Java no hay sintaxis para contratos (otros lenguajes sí la tienen), así que se documentan con Javadoc, que ya conoces del módulo 1:

Ventajas de escribirlo:

• El llamador sabe qué debe cumplir sin leer la implementación. Eso es, literalmente, la definición de abstracción.
• Te obliga a ti, al escribirlo, a pensar en los casos límite: ¿qué pasa si ya estaba devuelto? ¿Y si los días son negativos? Muchos contratos revelan huecos de diseño antes de que existan como bugs.
• El IDE lo muestra al autocompletar, así que el contrato viaja con el código.

Y una guía práctica sobre precondiciones: hay dos estrategias, y conviene elegir conscientemente.

Comprobarlo todo en todas partes multiplica el código sin aportar seguridad: si un método private solo lo llaman otros dos métodos de la misma clase que ya validaron, volver a validar es ruido.

Una buena abstracción habla el idioma del negocio. Si un bibliotecario de Nexus Software leyera tu código por encima del hombro, debería reconocer las palabras.

Compara:

A la idea de usar un único vocabulario compartido entre el código, la documentación y las conversaciones con el negocio se le llama lenguaje ubicuo. Su regla práctica es simple: si el negocio dice "multa", el código dice multa, no penaltyAmount, fee ni charge.

El vocabulario de BiblioTech, que llevas usando desde el módulo 1, es exactamente esto: titulo, autor, isbn, disponible, diasRetraso, multa, gravedad, referencia, prestar, devolver. Ninguna palabra técnica se ha colado en el dominio, y por eso prestamo.registrarDevolucion(20) se entiende sin abrir la clase.

El resultado tangible de una buena abstracción es que el llamador deja de saber cómo se hacen las cosas.

Recorre lo que ha pasado con el cálculo de la multa a lo largo del curso:

La prueba definitiva de que el qué y el cómo están separados es esta: ¿puedes cambiar la implementación sin tocar a los llamadores? Si Nexus Software decide mañana que la tarifa sea progresiva —0,25 € los siete primeros días y 0,50 € a partir del octavo—, ¿cuántos ficheros hay que tocar?

Un fichero. Ni main, ni el recibo, ni Prestamo se enteran. Eso es lo que compra la abstracción, y es la razón por la que se paga su coste en indirección.

La API pública de una clase es todo lo que otros pueden usar: métodos y campos public, y sus constructores. Es su promesa hacia el exterior.

Y esa promesa tiene un coste que casi nadie calcula al escribir el código:

La regla de oro:

Es fácil añadir un método público más tarde; es carísimo quitarlo. Ante la duda, déjalo private.

Aplicado a Prestamo, revisemos su API actual con un criterio severo:

Con esa poda, Prestamo pasa de más de veinte miembros públicos a catorce, y ninguno permite descuadrar el sistema. El ejercicio 1 te pide llevarla hasta el final.

Una abstracción con fugas (leaky abstraction) es la que promete ocultar un detalle pero obliga a conocerlo igualmente. La ley enunciada por Joel Spolsky dice, con algo de humor negro, que todas las abstracciones no triviales gotean: la cuestión no es evitarlo del todo, sino no agravarlo.

Ejemplos que ya has visto o verás:

Cómo reducir las fugas:

• Devuelve tipos inmutables o copias en lugar de estado interno.
• No expongas tipos de la implementación en la firma pública. Si mañana quieres cambiar un array por una lista, tu firma no debería obligarte a romper a nadie.
• Documenta lo que gotea cuando no puedas evitarlo. Una fuga documentada es un contrato; una fuga silenciosa es una trampa.

El vicio opuesto también existe, y en manos de alguien que acaba de descubrir la POO es el más frecuente: abstraer lo que nadie ha pedido.

Síntomas de sobreabstracción:

• Jerarquías de cinco niveles para tres casos concretos.
• Clases llamadas AbstractBaseGenericProcessorFactory.
• Parámetros de configuración que siempre valen lo mismo.
• Puntos de extensión "por si algún día" que nunca se usan.
• Una interfaz por cada clase, con una única implementación.

El principio que lo contiene se llama YAGNI: You Aren't Gonna Need It, "no lo vas a necesitar". Formulado como regla:

No añadas flexibilidad hasta que tengas dos casos reales que la requieran. Con uno, es adivinación.

Aplicado a BiblioTech, un contraste honesto:

Y una advertencia sobre el equilibrio: sobreabstraer es un error caro pero visible; infraabstraer produce el main de doscientas líneas del módulo 2, que también lo es. La respuesta profesional no es elegir un extremo, sino refactorizar cuando aparece el segundo caso. Es exactamente lo que has hecho: Material no existía hasta que aparecieron revistas y DVD.

Toda esta lección ha hablado de abstracción como disciplina: qué modelar, qué exponer, cómo separar niveles. Pero Java ofrece además dos mecanismos del lenguaje diseñados específicamente para materializarla, y ambos llegan en el módulo siguiente:

Dos carencias concretas del diseño actual que esos mecanismos resolverán:

Primera: Material se puede instanciar. Hoy nada impide escribir new Material("Algo", "REF-1", true), y eso no significa nada: en la biblioteca hay libros, revistas y DVD, no "materiales genéricos". Una clase abstracta lo prohíbe a nivel de compilador.

Segunda: getTipo() devuelve "Material" por defecto. Si alguien crea una subclase nueva y olvida sobrescribirlo, aparecerá "Material" en los listados sin que nadie lo detecte. Un método abstracto convierte ese olvido en un error de compilación:

Quédate con esto: en el módulo 4 aprenderás cómo se escriben; en esta lección has aprendido por qué existen. El orden importa, porque quien aprende interface sin haber entendido la abstracción acaba creando una interfaz por clase sin saber para qué.

• Confundir abstracción con encapsulamiento. Abstracción es qué expongo; encapsulamiento es cómo lo oculto. La tabla del apartado 2 los separa.
• Mezclar niveles en un método. Reglas de negocio y printf en el mismo bloque es el error más frecuente en código de principiante, y el más caro de deshacer.
• Meter presentación en las clases de dominio. Un Libro que sabe imprimir su ficha por consola no podrá reutilizarse en una web. La presentación va en otro paquete.
• Hacer público "por si acaso". Cada método público es un compromiso permanente. Empieza private y sube solo cuando alguien lo necesite de verdad.
• Nombres genéricos. Manager, Processor, Helper, Data, Info, Util. Si no puedes ponerle un nombre concreto a una clase, probablemente no sabes aún qué es.
• Documentar el cómo en lugar del qué. Un Javadoc que dice "recorre el array y suma" se queda obsoleto en cuanto cambies la implementación. Documenta el contrato: qué recibe, qué devuelve, qué garantiza.
• Abstraer sin un segundo caso. YAGNI. Espera a que aparezca el segundo soporte, la segunda base de datos, el segundo formato.
• Consejo: describe el método en una frase. Si necesitas "y" o "además", el método hace dos cosas y probablemente mezcla niveles.
• Consejo: lee tu código como si fueras el bibliotecario. Si p.registrarDevolucion(20) se entiende y dm.process(i, 20) no, ya sabes cuál está bien nombrado.
• Consejo: la prueba del cambio. Ante cada decisión de diseño, pregúntate qué habría que tocar si la regla cambiara. Cuantos menos ficheros, mejor la abstracción.

Este es el ejercicio central de la lección. Toma la clase Prestamo tal como quedó en 03-07 y reduce su superficie pública al mínimo necesario.

1. Lista todos sus miembros públicos actuales.
2. Para cada uno, decide: mantener, hacer private o eliminar, justificando la decisión en una frase.
3. Elimina getEmpleadoNoUsar() y sustituye sus usos por delegaciones adecuadas.
4. Escribe el Javadoc completo, con precondiciones y postcondiciones, de los tres métodos que consideres el núcleo de la clase.
5. Comprueba que BiblioTechApp y ReciboConsola siguen funcionando con la API reducida.

Refactoriza este método repartiendo cada línea a su nivel. Debe quedar: las reglas en el dominio, la presentación en ReciboConsola y el caso de uso reducido a tres o cuatro líneas legibles.

Para cada propuesta de un compañero, decide si está justificada, si es sobreabstracción (YAGNI) o si es una abstracción con fugas. Justifica en dos o tres frases y, cuando proceda, propón la alternativa.

1. Crear MaterialFisico y MaterialDigital como niveles intermedios entre Material y las tres clases actuales.
2. Añadir a Material un método public String[] getCamposInternos() que devuelva el estado en bruto "para depurar".
3. Extraer las cuatro constantes de negocio a una clase ReglasNegocio con métodos static.
4. Añadir a Prestamo un parámetro boolean modoSilencioso en registrarDevolucion para no imprimir avisos.

Solución 1

1 y 2. Revisión miembro por miembro:

3. Sustitución de los dos getters eliminados. Donde antes se escribía p.getMaterial().getTipo() o p.getEmpleadoNoUsar().getIdentificador(), se añaden delegaciones:

Son tres métodos triviales, y esa es la objeción habitual: "he cambiado un getter por tres". La respuesta es que ahora la clase controla qué se puede saber del empleado, y nadie puede llamar a registrarPrestamo() a sus espaldas. Se ha cambiado una puerta abierta por tres ventanas con reja.

4. Javadoc de los tres métodos núcleo:

Fíjate en un detalle del tercero: documentar "acepta nulos y responde false" es una decisión de diseño. Sin ella, cada llamador tendría que comprobar por su cuenta, o descubrir el comportamiento a base de NullPointerException.

5. ReciboConsola ya usaba solo delegaciones (getTituloMaterial(), getNombreEmpleado()), así que sigue compilando sin cambios. Es la señal de que la poda era correcta: lo que se ha eliminado no lo usaba nadie legítimo.

Solución 2

El método original mezcla cuatro niveles: interacción con el usuario, validación de reglas, creación del préstamo y presentación de resultados. Se reparte así.

Dominio. La comprobación combinada ya existe (Prestamo.sePuedePrestar) y el vencimiento lo calcula el constructor. No hay que añadir reglas nuevas, solo un método que explique por qué no se puede prestar:

Presentación. Todo el texto, en ReciboConsola:

Interacción con el usuario. También es presentación, así que la confirmación se aísla:

Caso de uso. Coordina y nada más:

Mejoras conseguidas, más allá de la longitud:

Solución 3

1. MaterialFisico / MaterialDigital — sobreabstracción (YAGNI). Hoy los tres materiales del catálogo son físicos, así que MaterialDigital no tendría ninguna subclase y MaterialFisico no aportaría ni un campo ni un método que Material no tenga ya. Añadiría un nivel a la jerarquía —justo lo que 03-05 desaconseja— a cambio de nada. Alternativa: esperar. El día que entre un curso en vídeo bajo demanda, con reglas propias de acceso, se introduce el nivel intermedio con un caso real en la mano.

2. getCamposInternos() — abstracción con fugas, y de las graves. Un método que devuelve "el estado en bruto" publica la representación interna como parte de la API: en cuanto alguien lo use en producción "solo para un log", ya no podrás cambiar los campos sin romperlo. Además invita a parsear la salida en lugar de usar los métodos. Alternativa: un toString() bien sobrescrito, que es exactamente para esto y se estudia en la lección siguiente. La depuración se hace con el depurador (02-05), que ve los campos privados sin necesidad de exponerlos.

3. Clase ReglasNegocio con las constantes — depende, y por eso es la más interesante. Como está formulada, es discutible: las constantes ya viven en Material, que es la clase que las usa, y sacarlas a un contenedor separado las alejaría de su significado; además getDiasPrestamo() y getTarifaDiaria() son polimórficas por soporte, así que una clase única no podría representarlas sin volver a un switch sobre el tipo, es decir, deshaciendo lo logrado en 03-06. Sí estaría justificada si esos valores tuvieran que leerse de un fichero de configuración o cambiar por sede, porque entonces habría un segundo caso real. Hoy no lo hay. Veredicto: YAGNI, con fecha de revisión.

4. Parámetro boolean modoSilencioso — mal por dos razones. La primera es la del apartado de buenas prácticas de 03-03: un parámetro booleano en la llamada no dice nada (registrarDevolucion(20, true) es ilegible). La segunda es más profunda: su existencia demuestra que la abstracción está rota, porque un método de dominio no debería imprimir nada, y por tanto no debería haber nada que silenciar. Alternativa: que registrarDevolucion no escriba en consola en absoluto y devuelva la información —lo hace, devuelve la multa—, dejando que la capa de presentación decida qué mostrar y cuándo. El "modo silencioso" desaparece porque el problema desaparece.

Un patrón que conviene reconocer en las cuatro respuestas: las propuestas 2 y 4 son parches sobre síntomas; una vez separados los niveles de abstracción, ninguna de las dos tiene razón de ser.

Has completado los cuatro pilares. La abstracción no es una palabra clave que se teclea, sino la disciplina de quedarse con lo esencial para el problema, y por eso el mismo libro se modela distinto en una biblioteca, una tienda y una imprenta. Sabes distinguirla del encapsulamiento —qué expongo frente a cómo lo oculto— y por qué necesitas las dos. Has aprendido a detectar y corregir la mezcla de niveles de abstracción, el vicio que convertía tu main del módulo 2 en un bloque ilegible, separando las reglas de negocio en el dominio, la presentación en su propio paquete y dejando el caso de uso en dos líneas. Sabes escribir contratos en Javadoc con precondiciones, postcondiciones e invariantes, y elegir conscientemente entre validar defensivamente o documentar y confiar. Modelas con el vocabulario del dominio, de modo que un bibliotecario de Nexus Software reconocería tu código. Has comprobado que separar el qué del cómo se paga solo: cambiar la política de multas a una tarifa progresiva afecta a un fichero. Y tienes criterio sobre los dos extremos: la API pública mínima frente al coste permanente de exponer de más, las abstracciones con fugas y el YAGNI que frena las jerarquías inventadas para casos que nadie ha pedido.

También sabes lo que falta: los dos mecanismos con que Java materializa todo esto —interfaces (04-01) y clases abstractas (04-02)— llegan en el módulo siguiente, y ahora sabrás para qué sirven, que es exactamente lo que le falta a quien los aprende antes de tiempo.

Queda una lección para cerrar el módulo, y es la que hace que tus objetos se comporten como ciudadanos de primera clase del lenguaje. Ahora mismo, imprimir un Libro produce un ilegible Libro@1b6d3586, y dos ejemplares con el mismo ISBN se consideran distintos porque equals compara direcciones de memoria. En La Clase Object: equals, hashCode y toString aprenderás el papel de la raíz de toda la jerarquía, el contrato completo de equals con sus cinco propiedades, por qué hashCode debe sobrescribirse siempre junto a él y qué se rompe si no lo haces. Y cumplirás la promesa que cierra el módulo 2: las tres variables sueltas mayorRetraso, empleadoMayorRetraso y libroMayorRetraso se convertirán por fin en un único objeto coherente.