Membros Virtuais
Nota
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.
Os membros virtuais podem ser substituídos, alterando assim 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 se sentem 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 para projetar, testar e manter porque qualquer chamada para 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 dos membros virtuais, de modo que o custo de projetá-los e documentá-los é maior.
❌ NÃO torne os membros virtuais a menos que tenha uma boa razão para fazê-lo e esteja ciente de todos os custos relacionados à conceção, teste e manutenção de membros virtuais.
Os membros virtuais são menos tolerantes em termos de alterações que podem ser feitas a eles sem quebrar a compatibilidade. Além disso, eles são mais lentos do que os membros não virtuais, principalmente porque as chamadas para membros virtuais não estão embutidas.
✔️ CONSIDERE limitar a extensibilidade apenas ao que é absolutamente necessário.
✔️ NÃO prefira a acessibilidade protegida sobre a 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 os consumidores diretos dessa classe. Os membros virtuais são projetados para serem substituídos em subclasses, e a acessibilidade protegida é uma ótima maneira de definir o escopo de todos os pontos de extensibilidade virtual para onde eles podem ser usados.
© Partes 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc., 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 por Addison-Wesley Professional como parte da Microsoft Windows Development Series.