Miembros protegidos
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.
Los miembros protegidos por sí mismos no proporcionan ninguna extensibilidad, pero pueden aumentar la eficacia de la extensibilidad a través de la creación de subclases. Se pueden usar para exponer opciones de personalización avanzadas sin complicar innecesariamente la interfaz pública principal.
Los diseñadores de marcos deben tener cuidado con los miembros protegidos, ya que el nombre "protegido" puede dar una falsa sensación de seguridad. Cualquier persona puede crear subclases de una clase no sellada y tener acceso a miembros protegidos, por lo que todas las mismas prácticas de codificación defensivas que se usan para los miembros públicos se aplican a los miembros protegidos.
✔️ CONSIDERE la posibilidad de usar miembros protegidos para la personalización avanzada.
✔️ TRATE los miembros protegidos de clases no selladas como públicos con fines de análisis de compatibilidad, documentación y seguridad.
Cualquier persona puede heredar de una clase y obtener acceso a los miembros protegidos.
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.