Resumen

  • Parnas comparó una descomposición por etapas de proceso con otra organizada en torno a decisiones que podían cambiar. Las dos podían compartir algoritmos y representación ejecutable; no compartían el mismo radio de cambio.
  • Dejar de guardar todas las líneas en memoria o cambiar el empaquetado de caracteres afectaba a todos los módulos del primer diseño y sólo a Line Storage en el segundo. Cambiar cómo se representan los desplazamientos afectaba a tres módulos frente a uno.
  • Ocultar información significa limitar quién debe conocer una decisión. No significa secreto, cifrado, aislamiento, orientación a objetos ni rendimiento gratuito; el propio artículo identifica una interfaz excesivamente específica como error.

Primero igualar la salida; después tocar la decisión

KWIC, Key Word in Context, nació como técnica de recuperación de información. H. P. Luhn publicó en 1960 un índice que situaba cada palabra significativa en el contexto de su título. Parnas tomó una versión reducida del problema: leer líneas, producir sus desplazamientos circulares, ordenarlos alfabéticamente y mostrarlos.

El tamaño era parte del método. El programa podía escribirse en una o dos semanas; por eso era posible mirar las costuras. El artículo de 1972 afirma que ambas soluciones funcionan. Incluso podrían usar los mismos algoritmos y, una vez ensambladas, ser idénticas al ejecutarse. La divergencia estaba en la asignación de responsabilidades y en la información que atravesaba sus interfaces.

Una demostración moderna podría empezar con una prueba que verifica idénticas salidas. No sería evidencia histórica de un experimento, sino una forma de entender el argumento. La prueba arquitectónica llega después: alterar almacenamiento, rotaciones u ordenación y enumerar qué propietarios deben cambiar su razonamiento.

La arquitectura del diagrama de flujo

La primera solución seguía las fases: Input, Circular Shift, Alphabetizing, Output y Master Control. Parecía modular porque cada tarea tenía un bloque. Sin embargo, las uniones incluían formatos de memoria, tablas, índices, punteros y convenciones. Cuatro caracteres se empaquetaban en una palabra de máquina; los módulos posteriores conocían los arrays de los anteriores.

La separación controlaba la secuencia de ejecución pero distribuía el conocimiento de decisiones volátiles. Cambiar una de ellas implicaba volver a visitar funciones que, en teoría, desempeñaban trabajos distintos.

La segunda solución cambió el criterio. Line Storage era dueño de la representación de líneas y ofrecía operaciones sobre caracteres y palabras. Circular Shifter hacía parecer que existía una colección de rotaciones, aunque pudiera almacenarlas, indexarlas o calcularlas bajo demanda. Alphabetizer controlaba la estrategia de ordenación. Input y Output se apoyaban en esas abstracciones.

En este vocabulario, módulo es una asignación de responsabilidad. No es sinónimo de subrutina. Un módulo puede aportar varias operaciones; el código final puede combinar partes de varios módulos. Tampoco una clase, un microservicio o un repositorio adquieren por su nombre la propiedad de ocultar una decisión.

La tabla de cambios era el argumento

Cambiar el formato de entrada quedaba dentro de Input en ambos diseños. Parnas no necesitó presentar una victoria absoluta.

El contraste aparecía al dejar de mantener todas las líneas en memoria. En la primera solución, cada módulo usaba el formato compartido y todos debían cambiar. En la segunda, sólo Line Storage conocía esa política. El resultado se repetía al abandonar el empaquetado de cuatro caracteres por palabra.

Modificar la forma de los desplazamientos—guardarlos completos, guardar un índice o calcular cada carácter cuando se solicitaba—alcanzaba a Circular Shift, Alphabetizer y Output en la primera solución. En la segunda quedaba dentro de Circular Shifter.

También podía cambiar el momento de ordenar: hacerlo una vez, buscar el siguiente elemento cuando fuera necesario o repartir el trabajo a lo largo de la producción. El primer Output esperaba un índice terminado. El segundo no podía detectar cuándo había ocurrido la ordenación.

La información ocultada no desaparece. Se asigna a un propietario. El beneficio consiste en que otros módulos ya no tienen derecho a basar su código en ella.

Una interfaz puede ser demasiado informativa

La autocrítica del artículo es crucial. La interfaz de Circular Shifter especificaba el orden de los desplazamientos: primero las líneas anteriores y, dentro de cada línea, el original antes que sus rotaciones. Los usuarios no necesitaban esa garantía. Había quedado excluida una implementación que produjera los desplazamientos ya ordenados y redujera Alphabetizer a una operación trivial.

Parnas llamó a ello un error de diseño. Aunque había ocultado el método de cálculo, había publicado un orden accidental. Encerrar campos tras métodos no resuelve el problema si los nombres, las formas de retorno, el orden o la temporización siguen copiando la implementación.

No es una teoría del secreto ni de las clases

Information hiding no trata de credenciales, cifrado o límites de proceso. Una información confidencial puede imponer su esquema a cada consumidor; una decisión pública puede estar perfectamente localizada. El objeto ocultado es el conocimiento necesario para cambiar el diseño.

Los tipos abstractos y la encapsulación son mecanismos útiles, pero no definiciones equivalentes. Una clase también puede exponer una taxonomía inestable. Cohesión y acoplamiento ofrecen lenguaje de evaluación posterior; todavía hace falta nombrar la decisión. Una dependencia de compilación tampoco equivale a una dependencia conceptual: recompilar no siempre exige reescribir, y desplegar por separado no elimina una suposición compartida.

El rendimiento queda fuera de toda garantía automática. Parnas advirtió que convertir cada operación pequeña en una llamada de procedimiento elaborada podía hacer más lenta la segunda solución. Propuso inserción de código y transferencias especializadas como posibilidades. La frontera de diseño y la forma de ejecución deben tratarse como problemas relacionados, no idénticos.

El ejemplo siguió cambiando

Años después, Parnas señaló que su KWIC aún permitía que todos los módulos supieran que una cadena era una secuencia de caracteres. Esa suposición común dificultaba representar cadenas frecuentes mediante enteros. Ni siquiera el ejemplo canónico había encontrado de una vez todas las decisiones correctas.

La idea tampoco quedó encerrada en un solo autor o año. El trabajo de 1971 describía las conexiones como supuestos entre módulos. En 1976, las familias de programas ampliaron el análisis a versiones emparentadas. En 1985, Parnas, Paul C. Clements y David M. Weiss distinguieron estructura modular, estructura de usos y estructura de procesos, y propusieron una guía de módulos para los mantenedores.

Más tarde, la comunidad de arquitectura de software volvió a KWIC para comparar datos compartidos, filtros, eventos y otros estilos. Esas extensiones no deben retroproyectarse sobre 1972. Lo que sí permanece es un instrumento sencillo: fijar el comportamiento visible, cambiar una decisión y observar hasta dónde viaja la obligación de conocerla.

Fuentes