Share via


Limitar la extensibilidad mediante clases selladas

Actualización: noviembre 2007

Puede utilizar las características de sellado para limitar las maneras en las que los desarrolladores pueden extender su marco de trabajo. Cuando se sella una clase, las demás clases no pueden heredar de ella. Cuando se sella un miembro, las clases derivadas no pueden reemplazar la implementación del miembro. No debería sellar tipos y miembros de forma predeterminada. El sellado impide la personalización de tipos y miembros de biblioteca y afecta a la percepción de utilidad que tienen algunos desarrolladores. Además, la extensibilidad es una de las ventajas fundamentales de utilizar un marco de trabajo orientado a objetos. Debería sopesar cuidadosamente decisiones que limitan esta ventaja.

No selle las clases sin tener una razón de peso para hacerlo.

No dé por supuesto que, debido a que no prevé ningún escenario en el que sería deseable extender una clase, es adecuado sellar la clase. Debería sellar las clases que cumplen ciertas condiciones:

  • La clase es estática.

  • La clase contiene miembros protegidos heredados con información confidencial de seguridad.

  • La clase hereda muchos miembros virtuales y los costos de desarrollo y pruebas de sellar cada uno de los miembros por separado son significativamente mayores que sellar toda la clase.

  • La clase es un atributo que requiere poder realizar búsquedas rápidas mediante la reflexión. Sellar un atributo mejora el rendimiento de reflexión al recuperar atributos.

No declare miembros protegidos o virtuales en tipos sellados.

Si un tipo está sellado, no puede tener clases derivadas. Sólo se puede tener acceso a los miembros protegidos desde una clase derivada y los miembros virtuales sólo se pueden reemplazar en una clase derivada.

Plantéese sellar los miembros reemplazados.

Puede utilizar este enfoque para garantizar que las clases derivadas no modifican ni omiten el comportamiento exigido para la clase actual y todas las clases derivadas.

Portions Copyright 2005 Microsoft Corporation. Reservados todos los derechos.

Portions Copyright Addison-Wesley Corporation. Reservados todos los derechos.

Para obtener más información sobre las directrices de diseño, consulte el libro titulado "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" de Krzysztof Cwalina y Brad Abrams, publicado por Addison-Wesley, 2005.

Vea también

Conceptos

Clases no selladas

Otros recursos

Instrucciones de diseño para desarrollar bibliotecas de clases

Diseñar extensibilidad