Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Observação
Este conteúdo é reimpresso com permissão da Pearson Education, Inc., a partir de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisto na terceira edição. Algumas das informações nesta página podem estar desatualizadas.
Um dos recursos das estruturas orientadas a objetos é que os desenvolvedores podem estendê-las e personalizá-las de maneiras não previstas pelos designers de estrutura. Este é o poder e o perigo do design extensível. Quando você projeta sua estrutura, é, portanto, muito importante projetar cuidadosamente para extensibilidade quando é desejado e limitar a extensibilidade quando é perigoso.
Um mecanismo poderoso que impede a extensibilidade é a vedação. Você pode selar a classe ou os seus membros individualmente. A selagem de uma classe impede que os usuários herdem da classe. Selar um membro evita que os usuários sobreponham um determinado membro.
❌ NÃO feche aulas sem ter uma boa razão para o fazer.
Selar uma classe porque você não pode pensar em um cenário de extensibilidade não é um bom motivo. Os utilizadores de frameworks gostam de herdar de classes por várias razões não óbvias, como adicionar membros convenientes. Consulte Classes sem lacre para obter exemplos de motivos não óbvios pelos quais os utilizadores desejam herdar de um tipo.
Boas razões para selar uma classe incluem o seguinte:
A classe é uma classe estática. Consulte Design de classe estática.
A classe armazena segredos sensíveis à segurança em membros protegidos por herança.
A classe herda muitos membros virtuais e o custo de selá-los individualmente superaria os benefícios de deixar a classe sem lacre.
A classe é um atributo que requer uma pesquisa de tempo de execução muito rápida. Os atributos selados têm níveis de desempenho ligeiramente mais elevados do que os não selados. Consulte Atributos.
❌ NÃO declare membros protegidos ou virtuais em tipos selados.
Por definição, os tipos selados não podem ser herdados. Isso significa que os membros protegidos em tipos selados não podem ser chamados e os métodos virtuais em tipos selados não podem ser substituídos.
✔️ CONSIDERE selar os membros que você substituir.
Os problemas que podem resultar da introdução de membros virtuais (discutidos em Membros virtuais) também se aplicam às substituições, embora num grau ligeiramente menor. Selar uma substituição protege você desses problemas a partir desse ponto na hierarquia de herança.
© Trechos 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc., a partir de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 pela Addison-Wesley Professional como parte da Microsoft Windows Development Series.