A ver, tratemos de tener un intercambio civilizado sin insultos de por medio, y ver si podemos entender la naturaleza de la enorme diferencia entre tu marco de referencia y el mio:
Seguís hablando de cuestiones de bajo nivel, y yo estoy parado en otro lado. Yo estoy parado en el negocio, y por lo tanto manejo conceptos de negocio. Cómo se almacenan los datos en memoria me resulta completamente irrelevante ya que es un detalle de bajo nivel, que a menos que exista una verdadera razón (por ejemplo de performance) para considerar, en la práctica es un concern secundario a otros aspectos mucho más importantes para el negocio, como por ejemplo la mantenibilidad del código.
Tal vez la naturaleza del código que vos escribís sea de más bajo nivel, y requiera prestar atención a tales detalles de bajo nivel, pero honestamente lo dudo ya que en la enorme mayoría de los casos los sistemas son I/O bound más que CPU bound, a menos que trabajes en CERN o algo así.
No es mi caso. Yo priorizo SIEMPRE la legibilidad (por eso jamás usaría java) y optimizo a más bajo nivel SOLO cuando la situación lo amerita (por ejemplo luego de haber profileado y encontrado un cuello de botella cpu-bound específico en un hot path puntual).
Dicho esto, efectivamente
java NO SOPORTA arrays multi-dimensionales, lo que si soporta son "arrays de arrays" o como dije, arrays anidados.
Acá Te comparto un link que demuestra la diferencia entre arrays multi-dimensionales, y arrays anidados o "jagged arrays" en un lenguaje que SI lo soporta, para que veas la diferencia y de paso amplíes tu marco de referencia viendo algo que en java no existe pero en lenguajes modernos si.
Lo que comentás del ejemplo de tabla, efectivamente sería mucho mejor modelado con un array de 2 dimensiones, cosa que no es posible en java. La ventaja principal en este caso es que un array de arrays
NO EXPRESA el hecho de que la cantidad de "columnas" (segunda dimensión) para cada fila es invariable.
En un array de arrays yo podría tener esto:
arr[0] = { 1, 2, 3 }
arr[1} = { 1, 2, 3, 4, 5, 6 }
Y como verás, conceptualmente esa estructura de datos ya no representa tan adecuadamente una "tabla" o "grilla" (que debería ser cuadrada o rectangular, conceptualmente, donde cada fila tiene una IGUAL cantidad de columnas).
Respecto del mejor uso del Type System para representar conceptos, la idea es que con un type system más rico (no el de java, como vemos) se pueden modelar los conceptos de forma que
Los estados ilegales sean imposibles de representar.
En este caso puntual de los aviones y los pasajeros, vemos, como dije, que representar este concepto con jagged arrays es la PEOR opción de todas. Si java soportara arrays N-dimensionales, podríamos tener una mejor representación, pero incluso así, sería preferible siempre usar una clase Avion con una lista de pasajeros como describí arriba.
Respecto de tu comentario: Bueno, "pues elegante no es, pero funcionará":
Creo que esta es la filosofía general de java como lenguaje, y como
el lenguaje condiciona tu pensamiento, la gente cuyo marco de referencia se basa solamente en éste, tiende a generar código como el que escribiste arriba, que no solamente es un ejemplo de lo que indiqué antes sobre la falta de cohesión de los datos, sino que además es un ejemplo de una mala práctica relacionada al uso de valores mágicos para representar estados ilegales. En tu caso usaste -1 como indicativo de que no existe el "pin" en la lista, cuando en realidad en un lenguaje más rico podrías haber usado algo así:
Si te interesa te puedo profundizar un poco más sobre la gran cantidad de language features que no existen en java que utilicé en estas breves líneas, de nuevo, con el fin de que puedas ampliar un poco tu marco de referencia.
- Tuplas.
- LINQ
- Nullable Value Types
- Null Propagation
- Expression bodied members
- Targed-typed new
