Membros virtuais
Observação
Este conteúdo é reimpresso com permissão da Pearson Education, Inc. 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 revisado na terceira edição. Algumas das informações nesta página podem estar desatualizadas.
Os membros virtuais podem ser substituídos, alterando o comportamento da subclasse. Eles são bastante semelhantes aos retornos de chamada em termos da extensibilidade que fornecem, mas são melhores em termos de desempenho de execução e consumo de memória. Além disso, os membros virtuais são mais naturais em cenários que exigem a criação de um tipo especial de um tipo existente (especialização).
Os membros virtuais têm um desempenho melhor do que retornos de chamada e eventos, mas não têm um desempenho melhor do que os métodos não virtuais.
A principal desvantagem dos membros virtuais é que o comportamento de um membro virtual só pode ser modificado no momento da compilação. O comportamento de um retorno de chamada pode ser modificado em tempo de execução.
Membros virtuais, como retornos de chamada (e talvez mais do que retornos de chamada), são caros de projetar, testar e manter porque qualquer chamada a um membro virtual pode ser substituída de maneiras imprevisíveis e pode executar código arbitrário. Além disso, geralmente é necessário muito mais esforço para definir claramente o contrato de membros virtuais, portanto, o custo de projetá-los e documentá-los é maior.
❌ NÃO crie membros virtuais, a menos que você tenha um bom motivo para fazer isso e esteja ciente de todos os custos relacionados a criação, teste e manutenção de membros virtuais.
Os membros virtuais são menos indulgentes em termos de alterações que podem ser feitas a eles sem interromper a compatibilidade. Além disso, são mais lentos do que membros não virtuais, principalmente porque as chamadas para membros virtuais não são embutidas.
✔️ CONSIDERE limitar a extensibilidade a apenas o absolutamente necessário.
✔️ PREFIRA a acessibilidade protegida à acessibilidade pública para membros virtuais. Os membros públicos devem fornecer extensibilidade (se necessário) chamando um membro virtual protegido.
Os membros públicos de uma classe devem fornecer o conjunto certo de funcionalidades para consumidores diretos dessa classe. Os membros virtuais foram projetados para serem substituídos em subclasses, e a acessibilidade protegida é uma ótima forma de definir o escopo de todos os pontos de extensibilidade virtual para onde eles podem ser usados.
Portions © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc. das Diretrizes de Design do Framework: convenções, linguagens e padrões para bibliotecas do .NET reutilizável, 2ª edição por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da série de desenvolvimento do Microsoft Windows.