Filosofía de la ingeniería: Barbara Liskov, el contrato es el tipo

Ideas clave

• La abstracción tiene que ver con el comportamiento, no con la estructura. Un tipo es el contrato que cumple —las operaciones y su significado—, no los bits que almacena. Usas algo por sus promesas, nunca por su representación.
• Un subtipo debe honrar las promesas del supertipo. El principio de sustitución de Liskov: en cualquier lugar donde se espera un supertipo, un subtipo debe funcionar sin romper las suposiciones de quien lo invoca —precondiciones más débiles, postcondiciones más fuertes, invariantes preservadas.
• La modularidad significa razonar sobre una parte sin tener el todo en la cabeza. La definición precisa de Liskov: puedes entender y verificar un módulo de forma aislada, confiando en que sus dependencias cumplirán sus contratos. La abstracción es lo que legitima esa confianza.
• Convirtió la abstracción de datos en una primitiva de programación. De CLU a Argus y al Premio Turing 2008, una sola idea escala desde una estructura de datos hasta una base de datos distribuida: define el contrato, oculta el mecanismo.

El principio

“Sea φ(x) una propiedad demostrable sobre objetos x de tipo T. Entonces φ(y) debe ser verdadera para objetos y de tipo S, donde S es un subtipo de T.” – Barbara Liskov y Jeannette Wing¹

Leída con calma, esa es la formulación formal de lo que el campo hoy llama el principio de sustitución de Liskov, tomada de su artículo de 1994 con Jeannette Wing.¹ Despojada de la notación, dice algo casi severo: a un subtipo no se le permite sorprenderte. Cualquier cosa que pudieras demostrar como verdadera sobre el supertipo debe seguir siendo verdadera cuando, en su lugar, le entregas al programa un subtipo. El subtipo hereda las promesas del padre, no solo su forma —y si no puede cumplir esas promesas, no es un subtipo, por mucho que lo diga el verificador de tipos.

Detrás de esa severidad está la culminación de una sola idea que Liskov persiguió durante cuarenta años: un tipo se define por su comportamiento, no por su representación. Un módulo es un contrato —un conjunto de operaciones con un significado especificado— y el sentido entero del contrato es que puedes usar la cosa sin leer cómo está construida. La sustituibilidad no es más que esa convicción aplicada a la herencia: si S afirma ser una clase de T, entonces en todo lugar donde se prometió un T, un S tiene que honrar la misma promesa. La estructura puede diferir. El comportamiento, no.

Por qué esto importa es el hilo que recorre toda su carrera: los programas grandes solo son manejables si puedes razonar sobre una pieza sin sostener el todo en la cabeza. La palabra de Liskov para eso era modularidad, y con ella quería decir algo preciso: la capacidad de entender y verificar un módulo de forma aislada, confiando en que todo aquello de lo que depende cumplirá su contrato declarado. La abstracción de datos es lo que legitima esa confianza, y el subtipado conductual es lo que impide que la herencia la rompa en silencio. Es la misma convicción que subyace al argumento de que los buenos sistemas se construyen de modo que el gusto sea un sistema técnico que puedes examinar —un contrato que puedes enunciar y comprobar— en lugar de una tradición que absorbes leyendo toda la base de código.

Contexto

Barbara Jane Huberman Liskov nació el 7 de noviembre de 1939 en Los Ángeles, California.² Obtuvo una licenciatura en matemáticas, con una especialización menor en física, de la Universidad de California, Berkeley, en 1961.² Cuando solicitó ingreso a programas de posgrado en matemáticas en Berkeley y Princeton, Princeton no admitía mujeres en absoluto; en cambio se puso a trabajar, y encontró su camino hacia la computación temprana casi por accidente, programando en la Mitre Corporation y en Harvard antes de decidir que, después de todo, sí quería el doctorado.²

Obtuvo su doctorado en Stanford en 1968 —una de las primeras mujeres en Estados Unidos en recibir un doctorado de un departamento de ciencias de la computación.² Su asesor fue John McCarthy, el inventor de Lisp y uno de los fundadores del campo de la inteligencia artificial; su tesis construyó un programa para jugar finales de ajedrez, y en el camino ideó la heurística asesina (killer heuristic), un truco de ordenamiento de jugadas que aún se usa en la búsqueda en árboles de juego.² Vale la pena retener ese detalle: ella surgió desde la IA, bajo el hombre que acuñó el término, y luego se apartó de ella hacia el problema que la definiría —no cómo hacer que una máquina piense, sino cómo hacer que un programa grande sea comprensible.

Tras Stanford regresó a Mitre, donde dirigió el diseño del sistema operativo Venus —un sistema de tiempo compartido interactivo, pequeño y de bajo costo, construido para explorar cómo una arquitectura cuidadosa de máquina y software podía simplificar un sistema.²³ En 1972 se incorporó a la facultad del MIT, donde ha permanecido desde entonces, hoy como Institute Professor, el rango más alto que confiere la institución.² Venus le había enseñado la pregunta. La ansiedad de la crisis del software de principios de los años 1970 —el reconocimiento incipiente de que los programas habían crecido demasiado para que alguien pudiera razonar sobre ellos— la afiló. La respuesta se convirtió en CLU.

El trabajo

La abstracción de datos y el lenguaje CLU

A partir de 1973, Liskov y sus estudiantes en el MIT diseñaron y construyeron CLU, y es uno de los lenguajes más calladamente influyentes jamás creados —un lenguaje en el que casi nadie escribió código de producción, cuyas ideas hoy están en casi todo.⁴ Su concepto organizador era el cluster, del que el lenguaje toma su nombre: una unidad que agrupa una representación de datos junto con las operaciones permitidas sobre ella, y oculta la representación por completo tras ese conjunto de operaciones.⁴ El cluster era la realización concreta del tipo de dato abstracto —la idea de que un tipo debe ser conocido por sus usuarios solo por lo que hace, nunca por cómo almacena sus bits.⁴⁵

CLU no se detuvo ahí. Fue pionero o popularizó un conjunto notable de características que hoy son requisitos mínimos: iteradores, implementados como corrutinas con una sentencia yield, de modo que podías recorrer una colección sin exponer su estructura interna; manejo de excepciones estructurado con signal y except, tratado como parte del flujo de control normal en lugar de añadido a posteriori; polimorfismo paramétrico —tipos parametrizados con seguridad de tipos y restricciones, el ancestro de los genéricos—; tipos variantes con seguridad de tipos; y múltiples valores de retorno mediante asignación paralela.⁴ Los iteradores reaparecieron en Python, C# y Ruby. Los tipos parametrizados se convirtieron en los genéricos de Java y C#. El manejo de excepciones dio forma a Java y C++. Los diseñadores de Swift le dieron crédito a CLU por su nombre.⁴ El lenguaje fue un banco de semillas.

Pero las características eran consecuencia del principio. El argumento de Liskov era que la abstracción es el mecanismo mediante el cual gestionamos la complejidad —construyes algo difícil definiendo un límite limpio, especificando qué lo cruza, y luego sin tener nunca que pensar en ambos lados a la vez. CLU fue la prueba de que un lenguaje de programación podía hacer cumplir ese límite en lugar de meramente permitirlo. El compilador se convirtió en un aliado del contrato.

El principio de sustitución de Liskov

En 1987, Liskov dio una conferencia magistral en OOPSLA titulada “Data Abstraction and Hierarchy”, publicada al año siguiente en SIGPLAN Notices.⁶ La programación orientada a objetos estaba en ascenso, y con ella la idea de subtipos —tipos que heredan de otros tipos y los extienden. La pregunta de Liskov era la obvia que nadie había formulado con precisión: ¿cuándo es realmente seguro tratar un subtipo como su supertipo? Su respuesta, en las propias palabras de la conferencia, era una propiedad de sustitución: “Lo que se quiere aquí es algo como la siguiente propiedad de sustitución: si para cada objeto o1 de tipo S hay un objeto o2 de tipo T tal que para todos los programas P definidos en términos de T el comportamiento de P no cambia cuando se sustituye o1 por o2, entonces S es un subtipo de T.”⁶

La paráfrasis popular que verás por todas partes —“si S es un subtipo de T, entonces los objetos de tipo T pueden reemplazarse por objetos de tipo S sin alterar ninguna de las propiedades deseables del programa”— es una compresión fiel de eso.⁷ En 1994, Liskov y Jeannette Wing lo hicieron riguroso en el artículo “A Behavioral Notion of Subtyping”, estableciendo las condiciones que un verdadero subtipo debe cumplir: sus métodos no deben exigir más (precondiciones más débiles o iguales) ni prometer menos (postcondiciones más fuertes o iguales) que los del supertipo, y debe preservar las invariantes y las propiedades de historia del supertipo.¹ Esas condiciones, tomadas en conjunto, son lo que significa el subtipado conductual —y son la razón por la que las formulaciones coloquiales de “si parece un pato y grazna como un pato” no son suyas y pierden el sentido: parecer y graznar son forma; el principio trata de las promesas cumplidas.

El contraejemplo clásico es el cuadrado que hereda del rectángulo. Un Rectangle te deja fijar el ancho y el alto de forma independiente; un cliente puede fijar el alto y confiar en que el ancho no cambia. Un Square que hereda de él debe forzar que ambos sean iguales —de modo que fijar el alto cambia el ancho en silencio, y la suposición razonable del cliente queda violada.⁷ El cuadrado es-un rectángulo en el sentido del diccionario, y pasa toda verificación de tipos, y aun así no es un subtipo conductual, porque no puede cumplir las promesas del rectángulo. La lección entera reside en esa única forma: la herencia de la estructura no es la herencia del contrato.

Sistemas distribuidos: Argus y Thor

Liskov no se quedó en el diseño de lenguajes. A principios de los años 1980 construyó Argus, descrito como el primer lenguaje de alto nivel en dar soporte a la implementación de programas distribuidos —programas repartidos entre máquinas que fallan de forma independiente.²³ Argus, una extensión de CLU, introdujo los guardianes (objetos que encapsulan estado distribuido, a los que se accede mediante manejadores) y las acciones atómicas (transacciones que se completan por entero o no se completan en absoluto, incluso a través de fallos, coordinadas mediante confirmación en dos fases), y demostró el encauzamiento de promesas (promise pipelining), donde puedes emitir una llamada y seguir trabajando antes de que regrese su resultado.⁹ El problema difícil de la distribución es el fallo parcial —un nodo muere mientras los demás siguen vivos— y Argus puso la abstracción de datos a trabajar sobre él: un guardián es un contrato que se sostiene incluso cuando la red no.

Thor, en los años 1990, fue una base de datos distribuida orientada a objetos, que proporcionaba almacenamiento persistente confiable y de alta disponibilidad de objetos a los que accedían programas escritos en muchos lenguajes.²³ El hilo conductor desde CLU es exacto. Un cluster oculta una representación tras operaciones; un guardián oculta estado distribuido tras operaciones atómicas; un objeto de Thor oculta la persistencia tras una interfaz tipada. A toda escala —una estructura de datos, un servicio de red, una base de datos— el movimiento de Liskov es el mismo: define el contrato, oculta el mecanismo, y deja que el resto del sistema razone únicamente sobre el contrato.

El Premio Turing 2008 y el legado

En 2009, la ACM otorgó a Liskov el Premio A.M. Turing 2008 —el máximo honor de la computación— con la mención: “Por sus contribuciones a los fundamentos prácticos y teóricos del diseño de lenguajes de programación y de sistemas, especialmente en relación con la abstracción de datos, la tolerancia a fallos y la computación distribuida.”⁸ La mención extendida nombra el hilo conductor con precisión: hizo avanzar “la abstracción de datos, la modularidad, la tolerancia a fallos, la persistencia y los sistemas de computación distribuida.”⁸ Ya había recibido la Medalla IEEE John von Neumann en 2004 “por contribuciones fundamentales a los lenguajes de programación, la metodología de programación y los sistemas distribuidos”, y más tarde fue incorporada al National Inventors Hall of Fame (2012) y galardonada con la Medalla Benjamin Franklin (2023).²

El legado no es un lenguaje o un sistema que puedas señalar y ejecutar. Es que el modo en que los programadores en activo piensan hoy —“programa hacia una interfaz”, “depende de contratos, no de implementaciones”, “esta clase viola el LSP”— es el vocabulario de Liskov, absorbido tan por completo que la mayoría de quienes lo usan nunca han leído el artículo. Esta es la forma más profunda de influencia: cuando tu idea deja de atribuirse porque se ha vuelto el aire que respiramos.

El método

El método es consistente a lo largo de treinta años —sistemas operativos, diseño de lenguajes y bases de datos distribuidas.

Define el tipo por su comportamiento, no por su representación. El movimiento recurrente es trazar un límite, especificar exactamente qué lo cruza, y luego negarse a dejar que cualquiera de los dos lados dependa de los entresijos del otro. Un cluster, un guardián, un objeto de Thor son todos el mismo acto: un contrato que oculta un mecanismo.⁴⁵

Haz la modularidad literal, y luego hazla cumplir. La modularidad, para Liskov, no es una preferencia de organización del código —es la capacidad de razonar sobre un módulo de forma aislada, confiando en que sus dependencias cumplen sus contratos. El compilador de CLU hacía cumplir la barrera de abstracción en lugar de sugerirla con cortesía. La disciplina solo es real si la herramienta la comprueba.⁴

Un subtipo debe cumplir las promesas del supertipo. El subtipado conductual es el principio de que la herencia es un contrato, no una comodidad. Precondiciones más débiles, postcondiciones más fuertes, invariantes preservadas —el subtipo puede hacer más, pero nunca puede exigir más ni prometer menos que su supertipo.¹

Ataca el problema difícil en el límite. El fallo parcial en los sistemas distribuidos es brutal precisamente porque rompe tu capacidad de razonar localmente. La respuesta de Argus fue empujar la abstracción hacia el propio modelo de fallos —acciones atómicas y guardianes— de modo que un programador todavía pudiera razonar sobre una pieza sin simular cada manera en que la red podía desmoronarse.²³

Lleva una sola idea hasta el final. La abstracción de datos a la escala de una pila, de un servicio de red y de una base de datos es reconociblemente la misma idea. Liskov no inventó una filosofía nueva para cada dominio; encontró la que escalaba y la cabalgó desde un sistema de tipos de los años 1970 hasta un almacén distribuido de los años 1990.

Cadena de influencia

Quién la formó

John McCarthy. Su asesor doctoral en Stanford, el inventor de Lisp y uno de los fundadores de la IA, le dio tanto el rigor de la ciencia de la computación matemática como —por la vía de su giro alejándose de la IA hacia la estructura de los programas— el problema que se convirtió en la obra de su vida.² (Influencia directa)

La crisis del software y la era de la programación estructurada. Liskov se formó como investigadora justo cuando el campo admitió que los programas habían superado la comprensión humana. El movimiento de la programación estructurada —Dijkstra, Hoare, Wirth— había argumentado que el flujo de control debe disciplinarse para poder razonar sobre él. Liskov extendió la misma convicción a los datos: no basta con disciplinar cómo se mueve un programa; debes disciplinar qué significan sus datos y a quién se le permite ver cómo se almacenan. (Influencia formativa)

C.A.R. Hoare y la disciplina de la especificación. El trabajo de Hoare sobre precondiciones, postcondiciones e invariantes —razonar sobre los programas como aserciones lógicas— es el ancestro intelectual directo de las condiciones del subtipado conductual que ella y Wing hicieron precisas. (Influencia formativa)

A quién formó ella

Todo sistema de tipos moderno. Los genéricos en Java y C#, los iteradores en Python y C#, el manejo de excepciones en toda la familia C, el diseño de Swift —las características que CLU fue pionera en introducir son hoy el mobiliario por defecto de casi todo lenguaje.⁴

La práctica orientada a objetos. “Programa hacia una interfaz, no hacia una implementación”, la inversión de dependencias y la “L” entera del vocabulario SOLID son el principio de Liskov, operacionalizado. Una generación aprendió a detectar una subclase mala sin aprender jamás de quién había sido la idea.⁷

La ingeniería de sistemas distribuidos. Las acciones atómicas, las garantías transaccionales a través de nodos que fallan, y la práctica de tratar un servicio remoto como un contrato que sobrevive al fallo parcial se remontan a Argus y Thor.²³

El hilo conductor

Edsger Dijkstra argumentó que un programa debe estructurarse de modo que un ser humano pueda razonar sobre él —la programación estructurada era la disciplina del flujo de control al servicio de la corrección. Liskov es el linaje directo: hizo por los datos lo que Dijkstra hizo por el control, insistiendo en que el razonamiento modular requiere barreras de abstracción disciplinadas, no solo bucles disciplinados. Y mientras Thompson y Ritchie construyeron Unix y C en torno a componentes pequeños que “hacen una sola cosa bien” y se componen mediante interfaces limpias, Liskov dio la teoría del porqué esa composición es digna de confianza: un componente del que puedes depender es uno cuyo contrato puedes enunciar y cuyos subtipos lo honran. Incluso el compilador de Grace Hopper fue un acto de abstracción —mover la traducción hacia el interior de la máquina para que un ser humano pudiera razonar en sus propios términos; Liskov hizo de la abstracción misma la unidad del diseño de programas, en lugar de una comodidad que el compilador proporcionaba. (Puente de la serie)

Lo que extraigo de esto

La lección que guardo es que una interfaz es una promesa, y las únicas interfaces que valen algo son las que de verdad cumples. Es fácil escribir una firma de tipo; es difícil honrar todo lo que esa firma implica y no violarlo nunca en silencio bajo una subclase nueva o una refactorización. El principio de Liskov es el estándar al que someto un límite: no “¿pasa la verificación de tipos?”, sino “¿puede quien lo invoca confiar en esta cosa en todo lugar donde se confiaba en su padre, sin leer cómo está construida?”. Es la misma vara que la calidad como única variable —la pregunta nunca es si el código compila, sino si el contrato es real.

En el mundo en el que construyo ahora —agentes, bucles de herramientas, sistemas de IA— la convicción de Liskov es más estructural que nunca, porque los componentes que compongo son opacos por naturaleza. Una herramienta, un subagente, una llamada a un modelo es un módulo: lo invocas sobre un contrato y no puedes leer sus entrañas. El juego entero está en si ese contrato se sostiene —si una herramienta que afirma “buscar en la base de código” de verdad devuelve lo que prometió su especificación, o si intercambiar un modelo por otro debilita en silencio una postcondición de la que dependía el resto del sistema. Ese es el principio de sustitución de Liskov vestido con ropa de 2026: un componente sustituido debe cumplir las promesas del que reemplazó. La disciplina de enunciar contratos y de comprobar que los subtipos los honran es exactamente la disciplina que hace que la puerta de la evidencia sea más que un eslogan —un sistema sobre el que puedes razonar por piezas porque cada pieza cumple su palabra.

Preguntas frecuentes

¿Cuál es la filosofía de ingeniería de Barbara Liskov?

La convicción central de Liskov es que un tipo se define por su comportamiento, no por su representación, y que eso es lo que hace manejables a los programas grandes. Un módulo es un contrato —un conjunto de operaciones con significados especificados— y el propósito del contrato es que puedas usar el módulo sin entender cómo está construido. Esta idea de la abstracción de datos recorre todo lo que construyó, desde el lenguaje CLU hasta el sistema distribuido Argus, y produjo su resultado más célebre: el principio de que un subtipo debe honrar cada promesa que hace su supertipo.⁴⁵¹

¿Qué es el principio de sustitución de Liskov?

Es la exigencia de que un subtipo pueda usarse en cualquier lugar donde se espere su supertipo, sin romper las suposiciones de quien lo invoca. Formalmente, en el enunciado de Liskov y Wing de 1994: “Sea φ(x) una propiedad demostrable sobre objetos x de tipo T. Entonces φ(y) debe ser verdadera para objetos y de tipo S, donde S es un subtipo de T.”¹ En su conferencia magistral de OOPSLA de 1987 lo planteó como una propiedad de sustitución: si sustituir un objeto de tipo S por uno de tipo T deja inalterado el comportamiento de todo programa, entonces S es un subtipo de T.⁶ En la práctica, un verdadero subtipo no debe exigir más que su supertipo (precondiciones más débiles o iguales), no debe prometer menos (postcondiciones más fuertes o iguales) y debe preservar sus invariantes. Las formulaciones populares del estilo “si parece un pato” no son de Liskov y pierden el sentido: el principio trata de las promesas cumplidas, no del parecido superficial.⁷

¿Qué inventó Barbara Liskov?

Diseñó y lideró la implementación del lenguaje de programación CLU (iniciado en 1973), que introdujo o popularizó los tipos de datos abstractos, los iteradores, el manejo estructurado de excepciones y el polimorfismo paramétrico —características hoy estándar en Java, C#, Python, Swift y otros.⁴ Antes había construido el sistema operativo de tiempo compartido Venus; más tarde creó Argus, el primer lenguaje de alto nivel para programas distribuidos, y Thor, una base de datos distribuida orientada a objetos.²³ Junto con Jeannette Wing formalizó el subtipado conductual, hoy llamado el principio de sustitución de Liskov.¹

¿Por qué ganó Barbara Liskov el Premio Turing?

La ACM le otorgó el Premio A.M. Turing 2008 “por sus contribuciones a los fundamentos prácticos y teóricos del diseño de lenguajes de programación y de sistemas, especialmente en relación con la abstracción de datos, la tolerancia a fallos y la computación distribuida.”⁸ El reconocimiento abarca toda su carrera: convertir la abstracción de datos en una primitiva del lenguaje de programación a través de CLU, hacer avanzar la modularidad y la teoría del subtipado, y poner esas ideas a trabajar sobre el problema difícil de construir sistemas confiables a través de máquinas que fallan de forma independiente. Fue una de las primeras mujeres en Estados Unidos en obtener un doctorado en ciencias de la computación (Stanford, 1968) y es Institute Professor en el MIT.²

Fuentes