Sellamiento

Nota:

Este contenido se reimprime con permiso de Pearson Education, Inc. de Directrices de diseño de frameworks: Convenciones, expresiones y patrones para bibliotecas reutilizables de .NET, 2ª edición. Esa edición fue publicada en 2008, y el libro ha sido totalmente revisado en la tercera edición. Parte de la información de esta página puede estar obsoleta.

Una de las características de los marcos orientados a objetos es que los desarrolladores pueden ampliarlas y personalizarlas de maneras imprevistas por los diseñadores de marcos. Esto es tanto el poder como el peligro del diseño extensible. Al diseñar el marco, es, por lo tanto, muy importante diseñar cuidadosamente la extensibilidad cuando se desea, y limitar la extensibilidad cuando sea peligroso.

Un mecanismo eficaz que impide la extensibilidad es el sellado. Puede sellar los miembros individuales o de clase. El sellado de una clase impide que los usuarios hereden de la clase . Sellar un miembro impide que los usuarios invaliden un miembro determinado.

❌ NO selle clases sin tener una buena razón para hacerlo.

Sellar una clase porque no puede pensar en un escenario de extensibilidad no es una buena razón. A los usuarios del marco les gusta heredar de clases por diversas razones no evidentes, como la incorporación de miembros de conveniencia. Consulte Clases no selladas para ver ejemplos de razones no evidentes por las que los usuarios quieren heredar de un tipo.

Entre las razones para el sellado de una clase se incluyen las siguientes:

  • La clase es una clase estática. Consulte Diseño de clases estáticas.

  • La clase almacena secretos que afectan a la seguridad en miembros protegidos heredados.

  • La clase hereda muchos miembros virtuales y el costo de sellarlos individualmente superaría las ventajas de dejar la clase sin sellar.

  • La clase es un atributo que requiere una búsqueda en tiempo de ejecución muy rápida. Los atributos sellados tienen niveles de rendimiento ligeramente mayores que los no sellados. Consulte Atributos.

❌ NO declare miembros protegidos ni virtuales en tipos sellados.

Por definición, los tipos sellados no se pueden heredar. Esto significa que no se puede llamar a miembros protegidos en tipos sellados y no se pueden invalidar los métodos virtuales en tipos sellados.

✔️ CONSIDERE la posibilidad de sellar los miembros que invalide.

Los problemas que pueden surgir de la presentación de miembros virtuales (como se indica en Miembros virtuales) se aplican también a las invalidaciones, aunque en un grado ligeramente menor. Sellar una invalidación le protege de estos problemas a partir de ese punto en la jerarquía de herencia.

© Partes 2005, 2009 de Microsoft Corporation. Todos los derechos reservados.

Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.

Consulte también