El CatalogoArray con el que cerraste la lección anterior funciona, pero tres de cada cuatro líneas son infraestructura: un contador n paralelo a length, un Arrays.copyOf para duplicar la capacidad, un System.arraycopy para tapar huecos, un null manual para no filtrar memoria. Ninguna de esas líneas habla de bibliotecas, de préstamos ni de empleados. Y aun con todo ese esfuerzo, el catálogo sigue sin poder garantizar que no haya ISBN repetidos sin recorrerlo entero, ni encontrar un material por su referencia en menos de O(n).

El Java Collections Framework es la respuesta del JDK a ese problema, y es una de las mejores piezas de diseño de la plataforma. No es "unas cuantas clases útiles": es una arquitectura de interfaces, implementaciones y algoritmos que lleva veinticinco años siendo el vocabulario común de todo programador Java. Aprenderla bien significa dos cosas. La primera, que dejarás de escribir infraestructura. La segunda, y más importante, que aprenderás a elegir la estructura de datos correcta, que es una de las decisiones que más impacto tiene en el rendimiento y en la claridad de un programa real.

Esta lección es el mapa. No entra a fondo en ninguna implementación —eso son las siete lecciones siguientes—, sino que te da la vista aérea: qué interfaces existen y cómo se relacionan, qué implementación elegir para cada problema, cómo funciona el recorrido por dentro y qué operaciones comparten todas las colecciones. La tabla maestra del apartado 4 es el corazón de todo el módulo; volverás a ella una y otra vez.

1. Qué es el Framework de Colecciones
2. La jerarquía de interfaces
3. Declara por la interfaz, instancia la implementación
4. La tabla maestra de implementaciones
5. Los genéricos en las colecciones
6. Iterable, Iterator y el for-each por dentro
7. ConcurrentModificationException: fail-fast explicado
8. Los métodos comunes de Collection
9. Colecciones inmutables y de conveniencia
10. Cómo elegir la colección correcta
11. Primer refactor de BiblioTech
12. Errores Comunes y Consejos
13. Ejercicios

Una colección es un objeto que agrupa varios elementos y sabe gestionarlos: añadir, quitar, buscar, contar, recorrer. Frente al array, una colección tiene tres virtudes decisivas:

• Crece y mengua sola. No hay capacidad que administrar.
• Tiene semántica. Un Set garantiza que no hay duplicados; una Queue garantiza el orden FIFO. El array no garantiza nada: solo guarda.
• Es intercambiable. Como todas implementan las mismas interfaces, cambiar ArrayList por LinkedList es cambiar una palabra.

El Framework se organiza en tres capas que conviene distinguir desde el principio:

Esa separación es la aplicación directa de todo lo que aprendiste en el módulo 4. List es una interfaz en el sentido exacto de 04-01: un contrato que dice qué se puede hacer sin decir cómo. ArrayList y LinkedList son dos implementaciones distintas del mismo contrato, y el polimorfismo de 03-06 permite intercambiarlas sin tocar el código que las usa. El Framework de Colecciones es, probablemente, el mejor ejemplo de diseño orientado a interfaces que vas a encontrar.

Todo vive en java.util, así que casi cualquier clase que escribas empezará con alguno de estos imports:

Esta es la estructura que hay que tener grabada:

Y aparte, sin ninguna relación de herencia con lo anterior:

Lee las dos jerarquías así, de arriba abajo:

• Iterable es la interfaz más general de todas y solo promete una cosa: "puedo darte un iterador para recorrerme uno a uno". Cualquier cosa que sea Iterable funciona con for-each. Fíjate en que un array no es Iterable —no es una clase, no implementa nada—; el for-each sobre arrays funciona porque el compilador lo trata como un caso especial (lo verás en el apartado 6).
• Collection añade el vocabulario básico de "grupo de elementos": add, remove, contains, size, isEmpty, clear. Es lo mínimo común a listas, conjuntos y colas.
• List: elementos ordenados por posición, con índice y duplicados permitidos. Es el equivalente natural del array.
• Set: sin duplicados, sin acceso por índice. Modela el concepto matemático de conjunto.
• Queue: elementos en un orden de proceso, normalmente FIFO. Se añade por un extremo y se consume por el otro.
• Deque: cola de doble extremo; sirve a la vez como cola y como pila.

Es la pregunta que hace todo el mundo la primera vez, y tiene una respuesta precisa: una Collection guarda elementos sueltos; un Map guarda pares clave→valor. Los métodos de Collection no tendrían sentido en un mapa:

• ¿Qué haría map.add(x)? ¿x es una clave, un valor, un par?
• ¿Qué devolvería map.iterator()? ¿Claves, valores o pares?
• ¿Qué comprobaría map.contains(x)? El mapa necesita dos preguntas distintas: containsKey y containsValue.

Forzar Map extends Collection habría producido una interfaz llena de métodos ambiguos o no soportados. La solución de diseño es más limpia: Map es una jerarquía independiente, y ofrece tres vistas que sí son colecciones:

Y esas tres vistas sí son Iterable, así que sí se recorren con for-each. Es lo mejor de ambos mundos: Map conserva su API propia y coherente, y sigue conectado al resto del Framework a través de sus vistas. En 05-05 lo verás en detalle.

Esta es la regla de oro del Framework, y probablemente el hábito profesional más rentable de esta lección:

A la izquierda del =, el tipo más general que cubra lo que necesitas (la interfaz). A la derecha, la implementación concreta. Los motivos:

1. Puedes cambiar de implementación tocando una palabra. Si mañana descubres que necesitas comportamiento de cola, cambias new ArrayList<>() por new LinkedList<>() y nada más del programa se entera. Si habías declarado ArrayList<Libro>, tienes que revisar cada declaración, cada parámetro y cada tipo de retorno.

2. Las firmas de tus métodos se vuelven flexibles. Compara:

La regla práctica en las firmas: pide el tipo más general que te sirva. Si solo recorres, Iterable o Collection. Si necesitas índices, List. Devolviendo, en cambio, conviene ser algo más específico para no ocultar garantías útiles (si devuelves algo sin duplicados, decláralo Set).

3. Comunicas la intención, no el mecanismo. List<Libro> dice "una secuencia ordenada con posible repetición". ArrayList<Libro> dice además "implementada sobre un array", un detalle interno que a quien llama no le importa.

Las excepciones son pocas y explícitas: cuando necesitas un método que solo existe en la implementación. ArrayList tiene trimToSize(), LinkedList tiene addFirst() heredado de Deque. En esos casos, declara por el tipo que ofrezca el método que realmente usas:

Y una nota sobre el operador diamante <>: desde Java 7, el tipo del lado derecho se deduce del izquierdo, así que new ArrayList<Libro>() se escribe new ArrayList<>(). Escríbelo siempre así.

Esta tabla es el corazón del módulo. Cada fila es una lección o un apartado de las siete siguientes, pero tenerlas juntas te da algo que ninguna lección aislada da: criterio de elección.

* Amortizado: casi siempre O(1), pero cuando el array interno se llena hay una copia O(n). Verás por qué el promedio sigue siendo O(1) en 05-03.

Lee la tabla por columnas y saldrán los patrones que de verdad importan:

• La columna "Orden" tiene tres valores. Ninguno significa que el orden de recorrido es impredecible y puede cambiar entre ejecuciones o al añadir elementos: nunca dependas de él. Inserción significa que se recorre en el orden en que metiste los elementos. Ordenado significa por Comparable o Comparator (05-09).
• La columna "O(1) frente a O(log n)" resume la diferencia entre las estructuras de hash (HashXxx) y las de árbol (TreeXxx): el hash es más rápido, el árbol mantiene el orden. Elegir es decidir si necesitas ese orden.
• La columna "null" es una fuente enorme de NullPointerException inesperadas. Las estructuras "modernas" (ArrayDeque, PriorityQueue) los rechazan a propósito, porque usan null como señal interna de "vacío". Las de árbol los rechazan porque no se puede comparar null con compareTo.
• Las filas en negrita del "cuándo elegirla" son las cuatro respuestas por defecto: ArrayList, HashSet, HashMap, ArrayDeque. Empieza siempre por una de ellas y cámbiala solo si tienes un motivo concreto.

Todas las colecciones son genéricas: llevan entre ángulos el tipo de elemento que contienen.

Por ahora, léelo así: <...> es el tipo de lo que hay dentro. List<Libro> es "una lista de libros". Map<String, Material> es "un mapa cuyas claves son cadenas y cuyos valores son materiales". Nada más.

Lo que ganas es seguridad en tiempo de compilación:

Antes de Java 5 las colecciones guardaban Object, y cada lectura requería un casting que podía fallar en ejecución:

Los genéricos mueven ese error del tiempo de ejecución al tiempo de compilación, que es exactamente donde quieres los errores. Nunca uses tipos crudos (sin <>); el compilador te avisará con unchecked warning y con razón.

Los genéricos solo aceptan tipos referencia, no primitivos. List<int> no compila; hay que escribir List<Integer>. El autoboxing de 01-04 hace la conversión automáticamente y el código parece natural:

Pero el coste es real y conviene conocerlo:

Para un millón de enteros, la diferencia es de unos 4 MB frente a más de 20 MB, y varias veces más lento al recorrer. En una aplicación de gestión da igual; en cálculo numérico intensivo, no. La regla: usa colecciones salvo que trabajes con muchos primitivos y el rendimiento sea crítico, en cuyo caso el array gana.

Hay además una trampa de comparación con Integer que ya viste en 01-05 y que reaparece aquí:

La teoría completa de los genéricos —parámetros de tipo propios (class Caja<T>), comodines (? extends, ? super), límites (<T extends Comparable<T>>) y el borrado de tipos que explica por qué List<int> es imposible— es la lección 10-01. En este módulo te basta con usar los genéricos existentes.

El for-each que aprendiste en 05-01 no es magia: es azúcar sintáctico. El compilador lo traduce a otra cosa, y saber a qué te va a explicar de golpe varios comportamientos que si no parecen arbitrarios.

Sobre un array, el compilador genera un for clásico:

Sobre un Iterable (cualquier colección), genera un bucle con un iterador:

Un Iterator es un objeto que representa una posición dentro de un recorrido y ofrece tres métodos:

El diseño es una aplicación preciosa del principio de 04-01: Iterator es un contrato que desacopla el recorrido de la estructura. Un ArrayList lo implementa moviendo un índice; una LinkedList, saltando de nodo en nodo; un HashSet, recorriendo cubetas. Tu bucle no se entera de ninguna de esas diferencias.

Normalmente no escribirás iteradores a mano. Hay una excepción importante, y es el motivo de que existan: eliminar elementos mientras recorres.

Y, como Iterable es la interfaz más general de todas, un método que solo recorre puede aceptarla y funcionar con cualquier origen de datos:

Iterable también ofrece forEach, que recibe un Consumer de los que dominaste en 04-06:

Es equivalente a un for-each y a veces más legible, sobre todo cuando ya tienes la referencia a método escrita. Y en el módulo 10 verás que stream() abre una tercera vía, mucho más expresiva, para filtrar, transformar y agrupar en una sola expresión; en este módulo recorreremos siempre con for-each, Iterator y los métodos propios de las colecciones.

Ahora, el error que produce más búsquedas en Internet de todo el Framework:

El nombre engaña: no hace falta ningún hilo concurrente. "Concurrente" aquí significa "durante el recorrido". Lo que ocurre es esto.

Cada colección lleva un contador interno llamado modCount (modification count) que se incrementa cada vez que su estructura cambia: cada add, cada remove, cada clear. Cuando pides un iterador, este guarda una copia del modCount actual. Y en cada next(), el iterador compara:

Si la colección cambió por detrás del iterador, los dos contadores difieren y el iterador se niega a continuar.

A esta política se le llama fail-fast: falla pronto y de forma ruidosa. Y es una virtud, no un capricho. Si el iterador siguiera adelante, el recorrido se desincronizaría y el resultado sería peor que una excepción: elementos saltados en silencio. Compruébalo con este ejemplo, que no lanza excepción y aun así está mal:

Al eliminar el elemento 0 de una lista de 3, el tamaño baja a 2 y el índice interno del iterador pasa a 1, con lo que hasNext() (que compara 1 != 2) da true, se devuelve "Nuria Vidal", el índice pasa a 2 y hasNext() da false: el bucle termina antes de tiempo y "Diego Alonso" nunca se visita. Si el elemento a borrar es el penúltimo, el recorrido acaba sin excepción y sin haber mirado el último. Ese es el escenario que el fail-fast intenta evitar; que a veces no salte es una casualidad del recuento, no una garantía.

1. Iterator.remove() — la solución clásica, válida en cualquier versión de Java:

2. removeIf(Predicate) — desde Java 8, la solución preferida por legibilidad:

Una línea, sin iterador visible, y con el Predicate de 04-06. Es lo que debes escribir por defecto.

3. Recorrer una copia — cuando necesitas modificar la original mientras la lees entera:

Cuesta memoria (duplica la lista) pero es imprescindible cuando la operación dentro del bucle puede añadir y quitar elementos.

4. Recorrer hacia atrás con índices — útil si necesitas la posición:

Hacia atrás, porque al eliminar el elemento i los siguientes se desplazan; recorriendo en sentido inverso, los ya visitados no se mueven.

Esa última fila importa: for (Material m : catalogo) { m.prestar(); } es perfectamente legal. modCount cuenta cambios estructurales en la colección, no cambios en los objetos que contiene.

Todo lo que sea Collection —cualquier List, Set o Queue— entiende este vocabulario:

Dos observaciones sobre el valor devuelto que resuelven problemas reales:

add devuelve boolean, y en un Set ese booleano vale oro. false significa "ya estaba", así que detectar duplicados es una línea:

remove y contains usan equals, no ==. De ahí que 03-09 insistiera tanto en implementarlo bien: si tu clase no sobrescribe equals, contains comparará referencias y un objeto "igual" pero distinto no se encontrará jamás.

Y toArray cierra el círculo con la lección anterior:

El new Material[0] no es un desperdicio: le dice al método qué tipo de array crear. Pasar new Material[lista.size()] también vale y suele ser algo más lento en las JVM modernas, por curioso que parezca. Usa siempre new Material[0].

Desde Java 9 hay métodos de fábrica que crean colecciones inmutables en una expresión:

Sus propiedades, que hay que conocer al detalle porque sorprenden:

• Totalmente inmutables: cualquier add, remove, set o clear lanza UnsupportedOperationException.
• No admiten null, ni como elemento, ni como clave, ni como valor: lanzan NullPointerException al crearlas.
• Set.of y Map.of rechazan duplicados al construir, con IllegalArgumentException. Es intencionado: si escribes Set.of("a", "a") casi seguro que es un error tuyo.
• Map.of admite hasta 10 pares. Para más, Map.ofEntries(Map.entry(k, v), ...).
• Su orden de recorrido no está garantizado y puede cambiar entre ejecuciones (en Set.of y Map.of está deliberadamente aleatorizado para que nadie dependa de él). List.of sí conserva el orden, porque una lista es ordenada por definición.

Son perfectas para constantes, tablas fijas y valores de configuración:

Collections.unmodifiableList hace algo parecido pero no igual: crea una vista de solo lectura sobre una lista existente.

Para una copia defensiva de verdad en un getter (el patrón de 03-07), unmodifiableList no basta si quien llama puede alcanzar la lista original. Lo correcto es List.copyOf(lista) o Collections.unmodifiableList(new ArrayList<>(lista)).

Y hay tres utilidades más para casos frecuentes:

Su valor está en un consejo de diseño que vale la pena adoptar ya: nunca devuelvas null donde se espera una colección. Devuelve una colección vacía. Quien llama podrá escribir for (Material m : catalogo.buscar(...)) sin comprobar nada, y desaparece toda una familia de NullPointerException.

Este árbol resuelve la inmensa mayoría de las decisiones reales:

Y en cinco preguntas, por si prefieres el formato lista:

1. ¿Busco por clave? → Map. (HashMap salvo que necesites orden.)
2. ¿Los duplicados son un error? → Set. (HashSet salvo que necesites orden.)
3. ¿Necesito posiciones e índices? → List. (ArrayList casi siempre.)
4. ¿Solo añado por un extremo y saco por el otro? → Deque / Queue. (ArrayDeque.)
5. ¿Siempre quiero atender primero al más urgente? → PriorityQueue.

Una advertencia sobre la optimización prematura: para colecciones de decenas o cientos de elementos, la diferencia de rendimiento entre implementaciones es irrelevante. Elige por semántica: Set cuando los duplicados sean un error conceptual, Map cuando exista de verdad una clave. Un Set<String> de ISBN documenta que los ISBN son únicos mejor que cualquier comentario. El rendimiento importa a partir de decenas de miles de elementos, y ahí la tabla del apartado 4 te dará la respuesta correcta.

Apliquemos ya lo aprendido al CatalogoArray de la lección anterior. Recuerda cómo era:

Y así queda con colecciones:

Uso:

Cuenta lo que ha desaparecido: el campo n, la comprobación de capacidad, el Arrays.copyOf para crecer, el System.arraycopy para borrar, el null manual, el recorte final del array de resultados. Y cuenta lo que ha aparecido: un Set<String> que garantiza en O(1) que no hay ISBN repetidos, algo que la versión con arrays no tenía y que habría costado un bucle O(n) en cada alta.

Sigue habiendo una debilidad, y es deliberada: eliminar y cualquier búsqueda por referencia recorren la lista entera, O(n). Con un Map<String, Material> sería O(1). Eso es 05-05.

Declarar por la implementación. ArrayList<Libro> lista = new ArrayList<>() funciona, pero te ata. Escribe List<Libro> lista = new ArrayList<>(). En los parámetros de tus métodos, pide el tipo más general que te sirva: Collection o Iterable si solo recorres.

Usar tipos crudos. List lista = new ArrayList(); compila con un aviso y devuelve Object, obligando a castings que fallan en ejecución. Pon siempre el <Tipo>.

Modificar la colección dentro de un for-each. Es la causa número uno de ConcurrentModificationException. Usa removeIf para criterios simples, Iterator.remove() para lógica compleja o recorre una copia si además añades.

Confiar en el orden de un HashSet o HashMap. No hay orden garantizado y puede cambiar al añadir elementos o entre versiones de Java. Si necesitas orden reproducible, usa las variantes Linked o Tree. Un test que dependa del orden de un HashSet es un test que fallará algún día.

Meter en un Set o usar como clave de Map objetos sin equals/hashCode correctos. El objeto se guardará pero no se encontrará nunca. En 05-05 verás la demostración exacta y el porqué; por ahora, si un objeto va a un Set o a una clave de Map, revisa 03-09.

Esperar que List.of sea modificable. Devuelve una lista inmutable. Si necesitas modificarla: new ArrayList<>(List.of(...)).

Confundir unmodifiableList con una copia. Es una vista: si alguien modifica la lista original, la vista cambia. Para una copia defensiva real, List.copyOf(lista).

Devolver null en lugar de una colección vacía. Obliga a quien llama a comprobar null en cada uso y garantiza NullPointerException el día que alguien lo olvide. Devuelve List.of() o Collections.emptyList().

Comparar Integer con == dentro de colecciones. Funciona hasta 127 por la caché de enteros y falla a partir de 128. Usa siempre equals, o compara con intValue().

Consejo de rendimiento: no optimices sin medir. Para 200 elementos, ArrayList y LinkedList son indistinguibles. Elige por semántica; el rendimiento aparece a partir de decenas de miles, y para entonces tendrás la tabla del apartado 4.

Para cada requisito de BiblioTech, indica qué interfaz y qué implementación usarías y por qué. Escribe también la declaración de la variable.

1. El catálogo completo, recorrido a menudo y mostrado en el orden en que se dio de alta.
2. Los ISBN ya catalogados, para rechazar altas duplicadas al instante.
3. Buscar un material por su referencia sin recorrer el catálogo.
4. Los préstamos pendientes de procesar, atendidos por orden de llegada.
5. Los avisos de vencimiento, atendiendo siempre primero al de más días de retraso.
6. Los tipos de material que existen, siempre listados alfabéticamente.
7. Las últimas 10 operaciones, para poder deshacer la más reciente.
8. Los días de préstamo por tipo, como constante del programa.

Escribe una clase PurgaCatalogo con tres métodos estáticos que reciban un List<Material> y eliminen los materiales cuyo título esté vacío o cuya referencia sea null:

• purgarConIterator(List<Material>), usando Iterator explícito.
• purgarConRemoveIf(List<Material>), en una línea.
• purgarSobreCopia(List<Material>), recorriendo una copia.

Añade un método demostrarError(List<Material>) que provoque a propósito la ConcurrentModificationException con un comentario que explique en qué momento exacto saltará.

Escribe una clase de utilidades Recorridos con métodos que acepten el tipo más general posible:

• int contar(Iterable<?> origen): cuenta elementos de cualquier cosa recorrible.
• String unir(Iterable<Material> materiales, String separador): concatena los títulos.
• double sumarTarifas(Collection<Material> materiales).
• List<Material> disponibles(Collection<Material> materiales): los que estén disponibles, devolviendo siempre una lista (vacía si no hay ninguno, nunca null).

Demuestra que todos funcionan igual con un ArrayList, un HashSet, un List.of(...) y el keySet() de un mapa cuando proceda.

Solución 1

La lección transversal del ejercicio: la colección correcta se deduce del enunciado. "Sin repetidos" dice Set. "Buscar por" dice Map. "Por orden de llegada" dice Queue. "Deshacer" dice pila. Si tienes que pensarlo mucho, probablemente el requisito no está bien formulado.

Solución 2

Las tres versiones válidas hacen lo mismo con costes distintos: removeIf y Iterator.remove operan sobre la lista original sin memoria extra; purgarSobreCopia duplica la lista, y solo compensa cuando el bucle también añade elementos. La versión de removeIf es además la única que se lee de un vistazo.

Solución 3

Demostración de que el tipo general es lo que da la flexibilidad:

Un solo método, contar, funciona sobre cinco orígenes distintos —incluidas las vistas de un mapa— porque pide Iterable, el contrato mínimo que todos cumplen. Es la regla de oro del apartado 3 llevada a las firmas de los métodos, y es lo que separa una API rígida de una reutilizable. Cuando en el módulo 10 conozcas los Streams, esta misma flexibilidad se expresará de forma aún más compacta, pero el principio será el mismo.

Ya tienes el mapa completo. Sabes que el Framework de Colecciones se organiza en tres capas —interfaces que definen contratos, implementaciones que eligen la estructura de datos y algoritmos que operan sobre cualquiera de ellas— y que esa separación es el mejor ejemplo de diseño orientado a interfaces del JDK. Conoces la jerarquía: Iterable → Collection → List/Set/Queue, con Deque extendiendo Queue y las variantes Sorted/Navigable; y sabes por qué Map va aparte: guarda pares, no elementos sueltos, y add, contains e iterator serían ambiguos en él. También sabes que se reconecta al resto del Framework mediante sus tres vistas: keySet, values y entrySet.

Has adoptado la regla de oro: List<Libro> catalogo = new ArrayList<>(). Declara por la interfaz, instancia la implementación, y pide en tus firmas el tipo más general que te sirva. Con eso, cambiar de implementación cuesta una palabra y tus métodos aceptan orígenes que ni habías previsto.

Tienes la tabla maestra de las diez implementaciones que usarás el resto de tu carrera, con su orden, sus duplicados, sus nulos y sus complejidades, y las cuatro respuestas por defecto grabadas: ArrayList, HashSet, HashMap, ArrayDeque. Y tienes el árbol de decisión para llegar a la elección correcta en cinco preguntas.

Entiendes los genéricos como usuario: <...> es el tipo de lo que hay dentro, da seguridad en compilación, elimina castings y obliga a Integer en lugar de int con un coste de memoria que conviene conocer —la teoría llega en 10-01—. Sabes que el for-each es azúcar sintáctico: sobre arrays se traduce a un for con índice, y sobre colecciones a un Iterator con hasNext/next. Y entiendes a fondo la ConcurrentModificationException: el modCount, la política fail-fast, por qué es una virtud, por qué a veces no salta y falla peor, y las cuatro soluciones con su criterio de elección, empezando por removeIf.

Dominas el vocabulario común de Collection —add con su boolean revelador, remove y contains apoyados en equals, addAll, retainAll, forEach, removeIf, toArray(new T[0])— y las colecciones inmutables, con la diferencia precisa entre List.of, Collections.unmodifiableList (una vista) y List.copyOf (una copia), más el consejo que elimina toda una familia de fallos: nunca devuelvas null donde se espera una colección.

Y BiblioTech ya lo nota. El Catalogo ha perdido el contador, la capacidad, el copyOf, el arraycopy y los null manuales, y ha ganado algo que antes no tenía: un Set<String> que garantiza en tiempo constante que no hay ISBN repetidos. Queda una debilidad evidente: buscar por referencia sigue recorriendo la lista entera.

En la lección siguiente, ArrayList, entrarás en la implementación que usarás más que ninguna otra. Verás cómo funciona por dentro —el array interno, la diferencia entre capacidad y tamaño, el redimensionado y por qué añadir sigue siendo O(1) "amortizado" aunque a veces copie un millón de elementos—, su API completa con la trampa clásica de remove(int) frente a remove(Object) en una List<Integer>, las conversiones entre array y lista con las trampas de cada una, y el refactor definitivo del catálogo de BiblioTech, con el antes y el después de un método real.