Sellar
Nota:
Este contenido se ha copiado con permiso de Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2ª edición. Esa edición se publicó en 2008 y el libro se ha revisado completamente 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 ampliarlos y personalizarlos de formas imprevistas para los diseñadores de marcos. Esta es la eficacia y el peligro del diseño extensible. Al diseñar el marco, es, por lo tanto, muy importante diseñar cuidadosamente para la extensibilidad cuando se desee y limitar esta cuando haya peligro.
Un mecanismo eficaz que evita la extensibilidad es el sellado. Puede sellar los miembros individuales o de clase. Sellar 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 por ver ejemplos de razones no evidentes que los usuarios desean heredar de un tipo.
Entre las razones buenas para sellar 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 de 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 de ahí. Esto significa que no se puede llamar a los miembros protegidos en tipos sellados y que tampoco 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.
Portions © 2005, 2009 Microsoft Corporation. Todos los derechos reservados.
Material reimpreso con el consentimiento de Pearson Education, Inc. y extraído de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (Instrucciones de diseño de .NET Framework: convenciones, expresiones y patrones para bibliotecas .NET reutilizables, 2.ª edición), de Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la serie Microsoft Windows Development.