Na programação orientada a objeto, o princípio do aberto/fechado estabelece que "entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação";[1]
isto é, a entidade pode permitir que o seu comportamento seja estendido sem modificar seu código-fonte.
O nome do princípio aberto/fechado tem sido usado de duas maneiras. Ambas as maneiras usam generalizações (por exemplo, herança , ou delegação de funções) para resolver o aparente dilema, mas os objetivos, as técnicas e os resultados são diferentes.
Um módulo será dito aberto se ele ainda está disponível para extensão. Por exemplo, se for possível adicionar campos para as estruturas de dados que ele contém, ou novos elementos para o conjunto de funções que executa.
Um módulo será dito ser fechado se está disponível para uso por outros módulos. Isso pressupõe que o módulo tenha sido bem-definido, isto é, que tenha uma descrição estável, em que as interfaces de programação fornecidas abstraem as características específicas do objeto.
No momento que Meyer estava escrevendo aquela obra, adicionar campos ou funções em uma biblioteca, inevitavelmente geraria alterações necessárias para todos os programas que dependiam daquela biblioteca. A solução proposta por Meyer para este dilema dependia da noção de herança presente na orientação a objetos (especificamente a herança de implementação):
Uma classe é fechada, uma vez que ela possa ser compilada, armazenada em uma biblioteca, baselined, e utilizada pelo cliente. Por outro lado, diz-se que ela é aberta quando qualquer nova classe pode usá-la como superclasse para a adição de novas funcionalidades. Quando criamos uma subclasse de uma classe aberta, não há necessidade de alterar a superclasse nem tampouco a forma com que seus clientes se relacionam com ela.
Princípio de aberto/fechado polimórfico
Durante a década de 1990, o princípio de aberto/fechado tornou-se redefinido popularmente para se referir ao uso de interfaces abstratas, onde as implementações podem ser alteradas e várias implementações poderiam ser criadas e polimorficamente substituídas por outras.
Em contraste com o uso de Meyer, esta definição defende a herança de classes base abstratas. Especificações de Interface podem ser reutilizadas através de herança, não sendo necessária uma implementação. A interface existente é fechada para modificações e novas implementações devem, no mínimo, implementar essa interface.