Barbara Liskov: A mulher que redefiniu abstrações e contratos em software
Quem é Barbara Liskov: tipos abstratos de dado, a linguagem CLU, o princípio de substituição na prática e o legado dela em sistemas distribuídos.
Neste artigo · 6 seções
Barbara Liskov não é “só” um nome em um princípio de SOLID, ela é uma das pessoas que literalmente redefiniram como a gente escreve software hoje, de OO a sistemas distribuídos. E em semana de Dia Internacional da Mulher, vale falar dela com a seriedade que a influência dela merece.
Quem é Barbara Liskov, de verdade
Barbara Jane Huberman Liskov nasceu em 1939 em Los Angeles e é cientista da computação norte‑americana, hoje professora no MIT em Engenharia Elétrica e Ciência da Computação. Ela se formou em Matemática em Berkeley em 1961 e, em 1968, se tornou a primeira mulher nos Estados Unidos a obter um PhD em Ciência da Computação, em Stanford, com uma tese sobre um programa que jogava finais de xadrez.
Ao longo da carreira, ela publicou mais de 140 artigos e liderou o Programming Methodology Group no MIT, atuando em linguagem de programação, metodologia de software e sistemas distribuídos. Em 2008 recebeu o prêmio Turing da ACM, o “Nobel da Computação”, por seu trabalho em linguagens de programação e metodologias de software que pavimentaram o caminho para a programação orientada a objetos moderna.
Ela também foi reconhecida com honrarias como a Medalha John von Neumann do IEEE e prêmios de impacto em linguagens e engenharia de software, além de ter sido incluída no National Inventors Hall of Fame. Em outras palavras, não estamos falando de uma figura simbólica, mas de alguém que mexeu diretamente na forma como nossos sistemas são pensados.
A ideia que mudou o jogo: tipos abstratos de dado
Antes de Liskov, organizar código grande era bem mais caótico: faltavam abstrações sólidas para estruturar sistemas em módulos com fronteiras claras. Ela introduziu o conceito de tipos abstratos de dado (ADTs) e de abstração de dados como forma principal de modularizar programas, separando o “o que” do “como”.
Para concretizar essa ideia, Liskov liderou o projeto da linguagem CLU no MIT, a primeira linguagem a suportar de forma sistemática data abstraction via “clusters”, que são essencialmente tipos abstratos de dado com operações bem definidas e implementação escondida. A arquitetura de CLU influenciou diretamente linguagens como Java, C++, C# e Ada, todas herdeiras das ideias de abstração de dados, modularidade e tratamento de exceções que ela consolidou.
Se hoje a gente fala de encapsulamento, invariantes de classe, módulos bem definidos, interfaces estáveis e implementação plugável, está bebendo da mesma fonte de abstração de dados que Liskov definiu e praticou em CLU. A coisa toda de tratar uma lista, um mapa, um repositório ou um serviço como contrato estável sobre o qual você pode trocar a implementação é justamente o tipo de pensamento que ela colocou no centro do design.
O tal do Liskov Substitution na prática
O famoso Liskov Substitution Principle (LSP) nasceu de uma keynote dela em 1987, “Data abstraction and hierarchy”, e foi formalizado depois em um artigo com Jeannette Wing. Em essência, o LSP diz que, se S é subtipo de T, então qualquer propriedade que vale para objetos de tipo T também deve valer para objetos de tipo S, de forma que um objeto de S possa substituir um de T sem quebrar o programa.
Ou, na linguagem mais de dia a dia: se você tem código que espera um T, pode passar um S sem que o comportamento esperado mude, nem as invariantes do sistema sejam violadas. É um requisito comportamental, não só sintático, por isso Liskov fala em “strong behavioral subtyping”: assinatura compatível não basta, o contrato tem que ser respeitado.
Quer ver isso bater na nossa realidade? Imagina algo assim em um domínio qualquer de pagamentos:
public class PaymentMethod {
public virtual void Refund(decimal amount) {
// lógica de estorno
}
}
public class GiftCard : PaymentMethod {
public override void Refund(decimal amount) {
throw new NotSupportedException("Gift cards não permitem estorno");
}
}A API grita que qualquer PaymentMethod aceita Refund, mas uma subclasse joga uma exceção inesperada em um fluxo que antes era seguro. Isso é uma violação clássica de LSP: o consumidor que programou para o tipo base não pode mais confiar nas regras que valiam antes. O princípio de Liskov existe justamente para evitar esse tipo de armadilha estrutural, que compila, passa pelo code review razoavelmente desatento e depois explode em produção de forma difícil de rastrear.
Esse tipo de reflexão que Liskov trouxe, sobre hierarquia de tipos, contratos e comportamento observável, é o fundamento por trás de muitos guidelines de design OO, desde SOLID até padrões de modelagem em DDD. A diferença é que ela formulou isso de forma formal, com foco em correção e verificabilidade, não só “boas práticas”.
De linguagens a sistemas distribuídos de verdade
Depois de CLU e das ideias de abstração de dados, Liskov mergulhou em sistemas distribuídos, focando em disponibilidade, tolerância a falhas e segurança de dados. Ela trabalhou em sistemas operacionais como o Venus, desenhado para suportar construção de software interativo e compartilhado em hardware de baixo custo, e depois evoluiu para linguagens e runtimes para sistemas distribuídos como Argus.
Um dos trabalhos marcantes é o Viewstamped Replication, um método de replicação primária para garantir alta disponibilidade em sistemas distribuídos, mesmo com falhas de nó. Depois, o grupo dela desenvolveu também o PBFT, Practical Byzantine Fault Tolerance, que é um dos protocolos mais citados quando falamos em sistemas que precisam continuar corretos mesmo com falhas arbitrárias, incluindo comportamento malicioso ou corrupção de rede.
Ela também pesquisou protocolos e mecanismos para armazenamento online confiável, garantindo confidencialidade e integridade de dados mesmo em presença de falhas de hardware e ataques. Quando hoje falamos em replicação, consenso, quorum, sistemas que “continuam em pé” em data centers diferentes e ainda assim mantêm invariantes de negócio, estamos pisando em terreno teórico que Liskov ajudou a consolidar.
Por que isso importa para quem lidera engenharia hoje
O que eu acho poderoso em estudar Barbara Liskov não é só decorar que ela definiu LSP ou ganhou o Turing. É conectar isso com decisões bem mundanas que tomamos como tech leads, heads ou arquitetos.
Quando você define um boundary de contexto num sistema distribuído, escolhe quais operações expor, quais invariantes garantir por contrato e como esconder detalhes de infraestrutura por trás de um serviço, está aplicando abstração de dados do jeito que Liskov imaginou décadas atrás. Quando discute se uma hierarquia de classes está valendo a pena ou se deveria ser composição com interfaces mais estáveis, está lidando com a diferença entre subtipagem sintática e comportamental que ela formalizou.
E quando alguém da equipe defende que “tá tudo bem” uma subclasse jogar exceção onde o tipo base não jogava, ou mudar sem aviso uma pré‑condição, é justamente o tipo de desvio que se evita se o time internaliza o Liskov Substitution de forma séria. A consequência prática aparece como menos bugs sutis, menos contratos traiçoeiros e uma base de código que envelhece melhor.
Tem também o aspecto de exemplo. Liskov foi a primeira mulher a fazer doutorado em Ciência da Computação nos EUA e uma das primeiras mulheres a ganhar o prêmio Turing, depois de uma carreira inteira em pesquisa pesada, liderança técnica e ensino. Em um mercado que ainda luta com diversidade em liderança técnica, ter esse tipo de referência ajuda bastante quando você quer mostrar para o time que há, sim, mulheres que não só participam do jogo, mas mudam as regras.
Insights & Takeaways
- Barbara Liskov não é “só” o L do SOLID, ela definiu a forma como organizamos código via tipos abstratos de dado e abstração de dados.
- CLU, a linguagem que ela criou, foi o primeiro ambiente a levar data abstraction a sério e influenciou diretamente linguagens como Java, C++ e C#.
- O Liskov Substitution Principle é sobre comportamento, não só assinatura: subtipos têm que preservar invariantes e expectativas do tipo base.
- Nos sistemas distribuídos que rodamos hoje, muita coisa em replicação e tolerância a falhas se apoia em ideias como Viewstamped Replication e PBFT, frutos do trabalho dela.
- Em semana de Dia da Mulher, trazer Liskov para a conversa é lembrar que algumas das bases da nossa stack moderna foram construídas por uma mulher que liderou técnica e academicamente por décadas.
