Implementar explícitamente miembros de interfaz
Una interfaz es un contrato para admitir alguna funcionalidad. Las clases que implementan una interfaz deben proporcionar los detalles de implementación de los miembros especificados en la interfaz. Por ejemplo, la interfaz IEnumerator define las firmas de miembro que se deben implementar para admitir la enumeración sobre un conjunto de objetos, como una colección. Para implementar IEnumerator, una clase debe implementar los miembros Current, MoveNext y Reset.
Cuando una clase implementa explícitamente un miembro de interfaz, sólo se puede tener acceso al miembro utilizando una referencia a la interfaz. Esto tiene el efecto de ocultar el miembro de interfaz. Una razón habitual para implementar explícitamente un miembro de interfaz es no sólo cumplir el contrato de la interfaz, sino también mejorarlo en algún sentido (por ejemplo, para proporcionar métodos con definición de tipos inflexible que se deberían utilizar en lugar de los métodos con definición de tipo flexible de la interfaz). Otra razón frecuente de implementar explícitamente un miembro de interfaz es que los desarrolladores no deberían llamar al miembro de interfaz explícito. Por ejemplo, el miembro GetObjectData se implementa explícitamente con más frecuencia porque lo llama la infraestructura de serialización y no está pensado para ser llamado desde el código.
Las instrucciones de diseño siguientes ayudan a garantizar que su diseño de biblioteca sólo utiliza la implementación de interfaces explícita cuando es adecuado.
Evite implementar explícitamente los miembros de interfaz sin tener una razón de peso para hacerlo.
Entender la implementación explícita requiere un nivel avanzado de especialización. Por ejemplo, muchos desarrolladores no saben que un miembro implementado explícitamente es invocable públicamente aunque su firma sea privada. Por ello, los miembros implementados explícitamente no aparecen en la lista de miembros públicamente visibles. Implementar explícitamente un miembro también puede producir la conversión boxing innecesaria de tipos de valor.
Considere la posibilidad de implementar explícitamente miembros de interfaz si los miembros están pensados para que sólo se los llame a través de la interfaz.
Esto incluye principalmente los miembros que admiten la infraestructura de .NET Framework, como el enlace de datos o la serialización. Por ejemplo, la propiedad IsReadOnly está pensada para que solo tenga acceso a ella la infraestructura de enlace de datos utilizando una referencia a la interfaz ICollection<T>. La clase List<T> implementa explícitamente la propiedad porque cumple esta instrucción.
Considere la posibilidad de implementar explícitamente los miembros de interfaz para simular la variación (es decir, cambios de parámetros o tipos de valor devuelto en miembros reemplazados).
Esto se hace a menudo para proporcionar versiones con establecimiento inflexible de tipos de los miembros de interfaz.
Plantéese implementar explícitamente los miembros de interfaz para ocultar un miembro y agregar un miembro equivalente con un mejor nombre.
Esto cambia efectivamente el nombre de un miembro. Por ejemplo, Stream implementa Dispose explícitamente y proporciona el método Close en su lugar.
No utilice los miembros explícitos como límite de seguridad.
Implementar explícitamente un miembro no proporciona ninguna seguridad. Estos miembros son invocables públicamente utilizando una referencia a la interfaz.
Proporcione un miembro virtual protegido que ofrezca la misma funcionalidad que el miembro implementado explícitamente si la funcionalidad está pensada para su especialización por parte de clases derivadas.
Los miembros implementados explícitamente no se pueden reemplazar. Si se vuelven a definir en una clase derivada, es imposible para la clase derivada llame a la implementación de la clase base. Debe nombrar el miembro protegido utilizando el mismo nombre que el del miembro de la interfaz explícita o adjuntando Core al nombre del miembro de la interfaz.
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 “las instrucciones de diseño de Framework: Convenciones, frases realizadas y modelos para libro de bibliotecas reutilizables de .NET” de Krzysztof Cwalina y Brad Abrams, publicados por Addison-Wesley, 2005.
Vea también
Conceptos
Otros recursos
Instrucciones de diseño de miembros
Instrucciones de diseño para desarrollar bibliotecas de clases