Filosofia de Engenharia: Barbara Liskov, o Contrato É o Tipo

Principais conclusões

• Abstração tem a ver com comportamento, não com estrutura. Um tipo é o contrato que ele cumpre — as operações e o significado delas — e não os bits que armazena. Você usa a coisa pelas promessas que ela faz, nunca pela sua representação.
• Um subtipo precisa honrar as promessas do supertipo. O Princípio da Substituição de Liskov: em qualquer lugar onde se espera um supertipo, um subtipo precisa funcionar sem quebrar as suposições de quem o chama — pré-condições mais fracas, pós-condições mais fortes, invariantes preservados.
• Modularidade significa raciocinar sobre uma parte sem o todo. A definição precisa de Liskov: você consegue entender e verificar um módulo isoladamente, confiando que suas dependências cumprirão seus contratos. A abstração é o que torna essa confiança legítima.
• Ela transformou a abstração de dados em uma primitiva de programação. De CLU a Argus e ao Prêmio Turing de 2008, uma única ideia escala de uma estrutura de dados a um banco de dados distribuído: defina o contrato, esconda o mecanismo.

O princípio

“Seja φ(x) uma propriedade demonstrável sobre objetos x do tipo T. Então φ(y) deve ser verdadeira para objetos y do tipo S, onde S é um subtipo de T.” — Barbara Liskov e Jeannette Wing¹

Lida devagar, essa é a formulação formal do que o campo hoje chama de Princípio da Substituição de Liskov, do artigo dela com Jeannette Wing, de 1994.¹ Tire a notação e o que sobra diz algo quase severo: um subtipo não tem permissão para te surpreender. Tudo que você conseguisse provar como verdadeiro sobre o supertipo precisa continuar verdadeiro quando você entrega ao programa um subtipo no lugar. O subtipo herda as promessas do pai, não apenas a sua forma — e se não consegue cumprir essas promessas, não é um subtipo, não importa o que o verificador de tipos diga.

Por trás dessa severidade está o ponto culminante de uma única ideia que Liskov perseguiu por quarenta anos: um tipo é definido pelo seu comportamento, não pela sua representação. Um módulo é um contrato — um conjunto de operações com um significado especificado — e o sentido inteiro do contrato é que você consegue usar a coisa sem ler como ela é construída. A substituibilidade é apenas essa convicção aplicada à herança: se S afirma ser um tipo de T, então em todo lugar onde se prometeu um T, um S precisa honrar a mesma promessa. A estrutura pode diferir. O comportamento, não.

A razão pela qual isso importa é o fio que atravessa toda a carreira dela: programas grandes só são tratáveis se você consegue raciocinar sobre uma peça sem segurar o todo na cabeça. A palavra de Liskov para isso era modularidade, e ela queria dizer algo preciso com isso: a capacidade de entender e verificar um módulo isoladamente, confiando que tudo de que ele depende cumprirá o contrato declarado. A abstração de dados é o que torna essa confiança legítima, e a subtipagem comportamental é o que impede a herança de quebrá-la silenciosamente. É a mesma convicção que sustenta o argumento de que bons sistemas são construídos de modo que o bom gosto é um sistema técnico que você pode examinar — um contrato que você pode declarar e verificar — em vez de uma tradição que você absorve lendo a base de código inteira.

Contexto

Barbara Jane Huberman Liskov nasceu em 7 de novembro de 1939, em Los Angeles, Califórnia.² Ela fez bacharelado em matemática, com minor em física, pela Universidade da Califórnia, Berkeley, em 1961.² Quando se candidatou a programas de pós-graduação em matemática em Berkeley e Princeton, Princeton não admitia mulheres de forma alguma; ela foi trabalhar em vez disso e encontrou seu caminho na computação inicial quase por acidente, programando na Mitre Corporation e em Harvard antes de decidir que afinal queria o doutorado.²

Ela obteve o PhD em Stanford em 1968 — uma das primeiras mulheres nos Estados Unidos a receber um doutorado de um departamento de ciência da computação.² Seu orientador foi John McCarthy, o inventor do Lisp e um dos fundadores do campo da inteligência artificial; sua tese construiu um programa para jogar finais de xadrez e, ao longo do caminho, ela concebeu a killer heuristic, um truque de ordenação de jogadas ainda usado na busca em árvore de jogo.² Vale segurar esse detalhe: ela veio da IA, sob o homem que cunhou o termo, e então se afastou dela em direção ao problema que a definiria — não como fazer uma máquina pensar, mas como tornar um programa grande compreensível.

Depois de Stanford ela voltou à Mitre, onde liderou o projeto do sistema operacional Venus — um sistema de tempo compartilhado interativo, pequeno e de baixo custo, construído para explorar como uma arquitetura cuidadosa de máquina e software poderia simplificar um sistema.²³ Em 1972 ela ingressou no corpo docente do MIT, onde permaneceu desde então, hoje Institute Professor, o mais alto título que a instituição concede.² Venus lhe ensinara a pergunta. A ansiedade da crise do software no início dos anos 1970 — o reconhecimento nascente de que os programas tinham ficado grandes demais para qualquer um raciocinar sobre eles — aguçou essa pergunta. A resposta veio a ser CLU.

O trabalho

A abstração de dados e a linguagem CLU

A partir de 1973, Liskov e seus alunos no MIT projetaram e construíram CLU, e ela é uma das linguagens mais silenciosamente influentes já feitas — uma linguagem na qual quase ninguém escreveu código de produção, mas cujas ideias estão hoje em praticamente tudo.⁴ Seu conceito organizador era o cluster, de onde a linguagem tira o nome: uma unidade que junta uma representação de dados com as operações permitidas sobre ela e esconde a representação inteiramente por trás desse conjunto de operações.⁴ O cluster foi a realização concreta do tipo abstrato de dados — a ideia de que um tipo deve ser conhecido por seus usuários apenas pelo que faz, nunca por como armazena seus bits.⁴⁵

CLU não parou aí. Ela foi pioneira ou popularizou um conjunto notável de recursos que hoje são o básico: iteradores, implementados como corrotinas com uma instrução yield, de modo que você pudesse percorrer uma coleção sem expor sua estrutura interna; tratamento de exceções estruturado com signal e except, tratado como parte do fluxo de controle normal em vez de algo improvisado por cima; polimorfismo paramétrico — tipos parametrizados com restrições e seguros quanto a tipo, o ancestral dos generics; tipos variantes seguros quanto a tipo; e múltiplos valores de retorno via atribuição paralela.⁴ Os iteradores reapareceram em Python, C# e Ruby. Os tipos parametrizados viraram generics em Java e C#. O tratamento de exceções moldou Java e C++. Os projetistas de Swift creditaram CLU pelo nome.⁴ A linguagem foi um banco de sementes.

Mas os recursos eram derivados do princípio. O argumento de Liskov era que a abstração é o mecanismo pelo qual administramos a complexidade — você constrói algo difícil definindo uma fronteira limpa, especificando o que a atravessa e então nunca mais tendo de pensar nos dois lados ao mesmo tempo. CLU foi a prova de que uma linguagem de programação poderia impor essa fronteira em vez de meramente permiti-la. O compilador virou um aliado do contrato.

O Princípio da Substituição de Liskov

Em 1987, Liskov deu uma palestra de abertura na OOPSLA intitulada “Data Abstraction and Hierarchy”, publicada no ano seguinte na SIGPLAN Notices.⁶ A programação orientada a objetos estava em ascensão, e com ela a ideia de subtipos — tipos que herdam de outros tipos e os estendem. A pergunta de Liskov era a óbvia que ninguém havia formulado com precisão: quando é, de fato, seguro tratar um subtipo como seu supertipo? A resposta dela, nas palavras da própria palestra, era uma propriedade de substituição: “O que se quer aqui é algo como a seguinte propriedade de substituição: se para cada objeto o1 do tipo S existe um objeto o2 do tipo T tal que, para todos os programas P definidos em termos de T, o comportamento de P permanece inalterado quando o1 é substituído por o2, então S é um subtipo de T.”⁶

A paráfrase popular que você verá em todo lugar — “se S é um subtipo de T, então objetos do tipo T podem ser substituídos por objetos do tipo S sem alterar nenhuma das propriedades desejáveis do programa” — é uma compressão fiel disso.⁷ Em 1994, Liskov e Jeannette Wing tornaram a ideia rigorosa no artigo “A Behavioral Notion of Subtyping”, dando as condições que um verdadeiro subtipo precisa satisfazer: seus métodos não podem exigir mais (pré-condições mais fracas ou iguais) nem prometer menos (pós-condições mais fortes ou iguais) que os do supertipo, e ele precisa preservar os invariantes e as propriedades de histórico do supertipo.¹ Essas condições, tomadas em conjunto, são o que significa a subtipagem comportamental — e são a razão pela qual as formulações coloquiais do tipo “se parece um pato e grasna como um pato” não são dela e perdem o ponto: parecer e grasnar são forma; o princípio trata de promessas cumpridas.

O contraexemplo clássico é o quadrado que herda do retângulo. Um Rectangle permite que você defina largura e altura de forma independente; um cliente pode definir a altura e confiar que a largura permanece inalterada. Um Square que herda dele precisa forçar os dois a serem iguais — então definir a altura altera silenciosamente a largura, e a suposição razoável do cliente é violada.⁷ O quadrado é-um retângulo no sentido do dicionário, passa em toda verificação de tipos e ainda assim não é um subtipo comportamental, porque não consegue cumprir as promessas do retângulo. A lição inteira está nessa única forma: herança de estrutura não é herança de contrato.

Sistemas distribuídos: Argus e Thor

Liskov não ficou no projeto de linguagens. No início dos anos 1980 ela construiu Argus, descrita como a primeira linguagem de alto nível a dar suporte à implementação de programas distribuídos — programas espalhados por máquinas que falham de forma independente.²³ Argus, uma extensão de CLU, introduziu guardians (objetos que encapsulam estado distribuído, acessados por meio de handlers) e ações atômicas (transações que ou se completam totalmente ou não acontecem de jeito nenhum, mesmo diante de falhas, coordenadas por commit de duas fases), e demonstrou o promise pipelining, em que você pode emitir uma chamada e continuar trabalhando antes que o resultado dela retorne.⁹ O problema difícil da distribuição é a falha parcial — um nó morre enquanto os outros vivem — e Argus pôs a abstração de dados a serviço disso: um guardian é um contrato que se sustenta mesmo quando a rede não.

Thor, nos anos 1990, foi um banco de dados distribuído orientado a objetos, oferecendo armazenamento persistente de objetos confiável e de alta disponibilidade, acessado por programas escritos em muitas linguagens.²³ O fio condutor que vem de CLU é exato. Um cluster esconde uma representação por trás de operações; um guardian esconde estado distribuído por trás de operações atômicas; um objeto Thor esconde a persistência por trás de uma interface tipada. Em toda escala — uma estrutura de dados, um serviço de rede, um banco de dados — o movimento de Liskov é o mesmo: defina o contrato, esconda o mecanismo e deixe o resto do sistema raciocinar apenas sobre o contrato.

O Prêmio Turing de 2008 e o legado

Em 2009, a ACM concedeu a Liskov o Prêmio A.M. Turing de 2008 — a maior honraria da computação — com a citação: “Por contribuições para os fundamentos práticos e teóricos do projeto de linguagens de programação e de sistemas, especialmente relacionadas à abstração de dados, à tolerância a falhas e à computação distribuída.”⁸ A citação estendida nomeia o fio condutor com precisão: ela avançou “a abstração de dados, a modularidade, a tolerância a falhas, a persistência e os sistemas de computação distribuída.”⁸ Ela já havia recebido a Medalha IEEE John von Neumann em 2004 “por contribuições fundamentais a linguagens de programação, metodologia de programação e sistemas distribuídos”, e foi posteriormente incluída no National Inventors Hall of Fame (2012) e agraciada com a Medalha Benjamin Franklin (2023).²

O legado não é uma linguagem ou um sistema que se possa apontar e executar. É que o modo como os programadores praticantes pensam hoje — “programe para uma interface”, “dependa de contratos, não de implementações”, “essa classe viola o LSP” — é o vocabulário de Liskov, absorvido tão completamente que a maioria das pessoas que o usa nunca leu o artigo. Esse é o tipo mais profundo de influência: quando sua ideia deixa de ser atribuída porque virou o ar que se respira.

O método

O método é consistente ao longo de trinta anos — sistemas operacionais, projeto de linguagens e bancos de dados distribuídos.

Defina o tipo pelo seu comportamento, não pela sua representação. O movimento recorrente é traçar uma fronteira, especificar exatamente o que a atravessa e então recusar-se a deixar que qualquer um dos lados dependa das entranhas do outro. Um cluster, um guardian, um objeto Thor são todos o mesmo ato: um contrato que esconde um mecanismo.⁴⁵

Torne a modularidade literal e então imponha-a. Modularidade, para Liskov, não é uma preferência de organização de código — é a capacidade de raciocinar sobre um módulo isoladamente, confiando que suas dependências cumprem seus contratos. O compilador de CLU impunha a barreira de abstração em vez de educadamente sugeri-la. A disciplina só é real se a ferramenta a verifica.⁴

Um subtipo precisa cumprir as promessas do supertipo. A subtipagem comportamental é o princípio de que herança é um contrato, não uma conveniência. Pré-condições mais fracas, pós-condições mais fortes, invariantes preservados — o subtipo pode fazer mais, mas nunca pode exigir mais nem prometer menos que seu supertipo.¹

Ataque o problema difícil na fronteira. A falha parcial em sistemas distribuídos é brutal precisamente porque quebra sua capacidade de raciocinar localmente. A resposta de Argus foi empurrar a abstração para dentro do próprio modelo de falhas — ações atômicas e guardians — de modo que um programador ainda pudesse raciocinar sobre uma peça sem simular todas as maneiras pelas quais a rede poderia desmoronar.²³

Carregue uma única ideia até o topo. A abstração de dados na escala de uma pilha, de um serviço de rede e de um banco de dados é reconhecivelmente a mesma ideia. Liskov não inventou uma filosofia nova para cada domínio; ela encontrou aquela que escalava e a conduziu de um sistema de tipos dos anos 1970 a um armazenamento distribuído dos anos 1990.

Cadeia de influência

Quem a moldou

John McCarthy. Seu orientador de doutorado em Stanford, o inventor do Lisp e um fundador da IA, lhe deu tanto o rigor da ciência da computação matemática quanto — por meio de seu afastamento da IA rumo à estrutura de programas — o problema que se tornou a obra de sua vida.² (Influência direta)

A crise do software e a era da programação estruturada. Liskov amadureceu como pesquisadora exatamente quando o campo admitiu que os programas tinham superado a compreensão humana. O movimento da programação estruturada — Dijkstra, Hoare, Wirth — havia argumentado que o fluxo de controle precisava ser disciplinado para ser objeto de raciocínio. Liskov estendeu a mesma convicção aos dados: não basta disciplinar como um programa se move; é preciso disciplinar o que seus dados significam e quem tem permissão de ver como são armazenados. (Influência formadora)

C.A.R. Hoare e a disciplina da especificação. O trabalho de Hoare sobre pré-condições, pós-condições e invariantes — raciocinar sobre programas como asserções lógicas — é o ancestral intelectual direto das condições de subtipagem comportamental que ela e Wing tornaram precisas. (Influência formadora)

Quem ela moldou

Todo sistema de tipos moderno. Generics em Java e C#, iteradores em Python e C#, tratamento de exceções por toda a família C, o projeto de Swift — os recursos que CLU foi pioneira são hoje o mobiliário padrão de praticamente toda linguagem.⁴

A prática orientada a objetos. “Programe para uma interface, não para uma implementação”, a inversão de dependência e o “L” de todo o vocabulário SOLID são o princípio de Liskov, operacionalizado. Uma geração aprendeu a identificar uma subclasse ruim sem nunca aprender de quem era a ideia.⁷

A engenharia de sistemas distribuídos. Ações atômicas, garantias transacionais entre nós que falham e a prática de tratar um serviço remoto como um contrato que sobrevive à falha parcial remontam a Argus e Thor.²³

O fio condutor

Edsger Dijkstra argumentou que um programa precisa ser estruturado de modo que um humano consiga raciocinar sobre ele — a programação estruturada era a disciplina do fluxo de controle a serviço da correção. Liskov é a linhagem direta: ela fez pelos dados o que Dijkstra fez pelo controle, insistindo que o raciocínio modular exige barreiras de abstração disciplinadas, não apenas laços disciplinados. E onde Thompson e Ritchie construíram o Unix e o C em torno de pequenos componentes que “fazem uma coisa bem feita” e se compõem por interfaces limpas, Liskov deu a teoria do porquê essa composição é confiável: um componente em que você pode se apoiar é aquele cujo contrato você consegue declarar e cujos subtipos o honram. Até o compilador de Grace Hopper foi um ato de abstração — mover a tradução para dentro da máquina para que um humano pudesse raciocinar nos seus próprios termos; Liskov tornou a própria abstração a unidade do projeto de programas, em vez de uma conveniência que o compilador oferecia. (Ponte da série)

O que eu levo disso

A lição que guardo é que uma interface é uma promessa, e as únicas interfaces que valem alguma coisa são aquelas que você de fato cumpre. É fácil escrever a assinatura de um tipo; difícil é honrar tudo que essa assinatura implica e nunca violá-la silenciosamente sob uma nova subclasse ou uma refatoração. O princípio de Liskov é o padrão pelo qual eu cobro uma fronteira: não “a verificação de tipos passa?”, mas “alguém que chama isto pode confiar nessa coisa em todo lugar onde confiava no pai dela, sem ler como ela é construída?”. É a mesma régua de a qualidade ser a única variável — a pergunta nunca é se o código compila, mas se o contrato é real.

No mundo em que construo agora — agentes, laços de ferramentas, sistemas de IA — a convicção de Liskov é mais estrutural do que nunca, porque os componentes que componho são opacos por natureza. Uma ferramenta, um subagente, uma chamada de modelo é um módulo: você o invoca sobre um contrato e não consegue ler suas entranhas. O jogo inteiro é se esse contrato se sustenta — se uma ferramenta que afirma “buscar na base de código” de fato retorna o que sua especificação prometeu, ou se trocar um modelo por outro enfraquece silenciosamente uma pós-condição da qual o resto do sistema dependia. Esse é o Princípio da Substituição de Liskov vestindo roupas de 2026: um componente substituído precisa cumprir as promessas daquele que ele substituiu. A disciplina de declarar contratos e verificar se os subtipos os honram é exatamente a disciplina que torna a barreira de evidências mais que um slogan — um sistema sobre o qual você consegue raciocinar em partes porque cada peça mantém sua palavra.

Perguntas frequentes

Qual é a filosofia de engenharia de Barbara Liskov?

A convicção central de Liskov é que um tipo é definido pelo seu comportamento, não pela sua representação, e que é isso que torna programas grandes tratáveis. Um módulo é um contrato — um conjunto de operações com significados especificados — e o propósito do contrato é que você consiga usar o módulo sem entender como ele é construído. Essa ideia de abstração de dados atravessa tudo que ela construiu, da linguagem CLU ao sistema distribuído Argus, e produziu seu resultado mais famoso: o princípio de que um subtipo precisa honrar toda promessa que seu supertipo faz.⁴⁵¹

O que é o Princípio da Substituição de Liskov?

É a exigência de que um subtipo seja utilizável em qualquer lugar onde se espera seu supertipo, sem quebrar as suposições de quem o chama. Formalmente, na formulação de Liskov e Wing de 1994: “Seja φ(x) uma propriedade demonstrável sobre objetos x do tipo T. Então φ(y) deve ser verdadeira para objetos y do tipo S, onde S é um subtipo de T.”¹ Em sua palestra de abertura na OOPSLA de 1987 ela a colocou como uma propriedade de substituição: se substituir um objeto do tipo S por um do tipo T deixa o comportamento de todo programa inalterado, então S é um subtipo de T.⁶ Na prática, um verdadeiro subtipo não pode exigir mais que seu supertipo (pré-condições mais fracas ou iguais), não pode prometer menos (pós-condições mais fortes ou iguais) e precisa preservar seus invariantes. As formulações populares do tipo “se parece um pato” não são de Liskov e perdem o ponto: o princípio trata de promessas cumpridas, não de semelhança superficial.⁷

O que Barbara Liskov inventou?

Ela projetou e liderou a implementação da linguagem de programação CLU (iniciada em 1973), que introduziu ou popularizou os tipos abstratos de dados, os iteradores, o tratamento estruturado de exceções e o polimorfismo paramétrico — recursos hoje padrão em Java, C#, Python, Swift e outras.⁴ Antes disso ela construiu o sistema operacional de tempo compartilhado Venus; depois criou Argus, a primeira linguagem de alto nível para programas distribuídos, e Thor, um banco de dados distribuído orientado a objetos.²³ Com Jeannette Wing ela formalizou a subtipagem comportamental, hoje chamada de Princípio da Substituição de Liskov.¹

Por que Barbara Liskov ganhou o Prêmio Turing?

A ACM lhe concedeu o Prêmio A.M. Turing de 2008 “por contribuições para os fundamentos práticos e teóricos do projeto de linguagens de programação e de sistemas, especialmente relacionadas à abstração de dados, à tolerância a falhas e à computação distribuída.”⁸ O reconhecimento abrange toda a carreira dela: tornar a abstração de dados uma primitiva de linguagem de programação por meio de CLU, avançar a modularidade e a teoria da subtipagem, e pôr essas ideias a serviço do problema difícil de construir sistemas confiáveis sobre máquinas que falham de forma independente. Ela foi uma das primeiras mulheres nos EUA a obter um PhD em ciência da computação (Stanford, 1968) e é Institute Professor no MIT.²

Fontes