Princípio do aberto/fechado

Origem: Wikipédia, a enciclopédia livre.
Saltar para a navegação Saltar para a pesquisa

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.

Princípio aberto/fechado de Meyer[editar | editar código-fonte]

Bertrand Meyer geralmente é creditado por ter originado a expressão do princípio aberto/fechado,[2] que apareceu em sua obra Software Orientação a objetos de Construção, de 1988.

  • Um módulo será dito para ser aberto se ele ainda está disponível para extensão. Por exemplo, deve ser 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 [ele] está disponível para uso por outros módulos. Isso pressupõe que o módulo tenha sido bem-definido, estável descrição (o interface no sentido de ocultar informações).

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 objeto (especificamente a herança de implementação):

Uma classe é fechado, uma vez que podem ser compilados, armazenados em uma biblioteca, baselined, e utilizados pelo cliente classes. Mas também é aberto, uma vez que qualquer nova classe pode usá-lo como pai, a adição de novas funcionalidades. Quando uma classe descendente é definida, não há necessidade de alterar o original ou perturbar seus clientes.

Princípio de aberto/fechado polimórfico[editar | editar código-fonte]

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 alterados 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ário uma implementação. A interface existente é fechada para modificações e novas implementações devem, no mínimo, implementar essa interface.

Robert C. Martin's no artigo, de 1996, "Open-Closed Princípio"[3] foi um dos seminais escritos para tomar essa atitude. Em 2001 Craig Larman relacionou o princípio aberto/fechado com o padrão, de Alistair Cockburn, chamado Variações Protegidas, e com a discussão de David Parnas sobre esconder informações.[4]

Veja também[editar | editar código-fonte]

  • SOLID – o "O" em "SOLID" está para o aberto/fechado princípio

Referências[editar | editar código-fonte]

  1. Meyer, Bertrand. Object-Oriented Software Construction. [S.l.: s.n.] ISBN 0-13-629049-3 
  2. Robert C. Martin "The Open-Closed Principle", C++ Report, January 1996, pp. 1 Arquivado em agosto 22, 2006[Erro data trocada], no Wayback Machine.
  3. Robert C. Martin "The Open-Closed Principle", C++ Report, January 1996 Arquivado em agosto 22, 2006[Erro data trocada], no Wayback Machine.
  4. Craig Larman, "Protegidos da Variação: A Importância de Ser Fechado", IEEE Software de Maio/junho de 2001, pp. 89-91 [1]

Links externos[editar | editar código-fonte]