Open–closed principle
Na programação orientada a objeto, o open/closed principle estados "entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação";[1]
isto é, como uma entidade pode permitir que o seu comportamento seja estendido sem modificar seu código-fonte.
O nome de aberto/fechado princípio tem sido usado de duas maneiras. Ambas as maneiras de usar generalizações (por exemplo, herança , ou delegar funções) para resolver o aparente dilema, mas os objetivos, as técnicas e os resultados são diferentes.
Meyer aberto/fechado princípio[editar]
Bertrand Meyer geralmente é creditado por ter originado o termo aberto/fechado princípio,[2] que apareceu em seu 1988 catálogo de Software Orientado a objetos de Construção.
- 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 Meyer foi escrito, adicionar campos ou funções de uma biblioteca, inevitavelmente, alterações necessárias para todos os programas, dependendo da biblioteca. Meyer proposta de solução para este dilema invocado a noção de orientação a objeto de herança (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.
Polimórficos aberto/fechado princípio[editar]
Durante a década de 1990, aberto/fechado princípio tornou-se popularmente redefinidos para se referir ao uso de abstraídos interfaces, onde as implementações podem ser alterados e várias implementações poderia ser criada e polimorficamente substituído por outro.
Em contraste com Meyer de uso, esta definição defende a herança de classes base abstratas. Especificações de Interface podem ser reutilizadas através de herança, mas a implementação não precisa de ser. A interface existente é fechado para modificações e novas implementações deve, no mínimo, implementam essa interface.
Robert C. Martin's de 1996, artigo "Open-Closed Princípio"[3] foi um dos seminais escritos para tomar essa atitude. Em 2001 Craig Larman relacionados aberto/fechado princípio ao padrão por Alistair Cockburn chamado Protegido de Variações, e para o David Parnas discussão de esconder informações.[4]
Veja também[editar]
- SOLID – o "O" em "SOLID" está para o aberto/fechado princípio
Referências[editar]
- ↑ Meyer, Bertrand. Object-Oriented Software Construction. [S.l.: s.n.] ISBN 0-13-629049-3
- ↑ Robert C. Martin "The Open-Closed Principle", C++ Report, January 1996, pp. 1 Arquivado em agosto 22, 2006[Erro data trocada], no Wayback Machine.
- ↑ Robert C. Martin "The Open-Closed Principle", C++ Report, January 1996 Arquivado em agosto 22, 2006[Erro data trocada], no Wayback Machine.
- ↑ 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]
- Os Princípios de INUNDAÇÃO
- Aberto/Fechado Princípio: Preocupações sobre a Mudança no Design de Software
- Aberto Fechado Princípio
- O Aberto-Fechado Princípio-e o Que se Esconde por Trás
Este artigo "Open–closed principle" é da wikipedia The list of its authors can be seen in its historical and/or the page Edithistory:Open–closed principle.
