Implementing Interface Members Explicitly
An interface is a contract for supporting some functionality. Classes that implement an interface must provide the implementation details for the members specified in the interface. For example, the IEnumerator interface defines the member signatures one must implement to support enumerating over a set of objects, such as a collection. To Implement IEnumerator, a class must implement the Current, MoveNext, and Reset members.
When an interface member is explicitly implemented by a class, the member can be accessed only by using a reference to the interface. This has the effect of hiding the interface member. A common reason for explicitly implementing an interface member is not only to comply with the interface's contract, but also to improve it in some way (for example, to provide strongly-typed methods that should be used in place of the interface's weakly-typed methods). Another common reason for implementing an interface member explicitly is when the explicit interface member should not be called by developers. For example, the GetObjectData member is most often explicitly implemented because it is called by the serialization infrastructure and is not intended to be called from code.
The following design guidelines help ensure that your library design uses explicit interface implementation only when appropriate.
Avoid implementing interface members explicitly without having a strong reason to do so.
Understanding explicit implementation requires an advanced level of expertise. For example, many developers do not know that an explicitly implemented member is publicly callable even though its signature is private. Because of this, explicitly implemented members do not appear in the list of publicly visible members. Explicitly implementing a member can also cause unnecessary boxing of value types.
Consider implementing interface members explicitly if the members are intended to be called only through the interface.
This mainly includes members that support the .NET Framework infrastructure, such as data binding or serialization. For example, the IsReadOnly property is intended to be accessed only by the data-binding infrastructure by using a reference to the ICollection interface. The List class implements the property explicitly because it meets this guideline.
Consider implementing interface members explicitly to simulate variance (that is, change parameters or return type in overridden members).
This is often done to offer strongly-typed versions of the interface members.
Consider implementing interface members explicitly to hide a member and add an equivalent member with a better name.
This effectively renames a member. For example, Stream implements Dispose explicitly and provides the Close method in its place.
Do not use explicit members as a security boundary.
Explicitly implementing a member does not provide any security. These members are publicly callable by using a reference to the interface.
Do provide a protected virtual member that offers the same functionality as the explicitly implemented member if the functionality is meant to be specialized by derived classes.
Explicitly implemented members cannot be overridden. If they are redefined in a derived class, it is impossible for the derived class to call the base class implementation. You should name the protected member by either using the same name as the explicit interface member or affixing Core to the interface member name.
Portions Copyright 2005 Microsoft Corporation. All rights reserved.
Portions Copyright Addison-Wesley Corporation. All rights reserved.
For more information on design guidelines, see the "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" book by Krzysztof Cwalina and Brad Abrams, published by Addison-Wesley, 2005.
See Also
Concepts
Other Resources
Member Design Guidelines
Design Guidelines for Developing Class Libraries