Abstract Types and InterfacesÂ
Abstract types and interfaces are both mechanisms for specifying programmatic abstractions. An abstraction specifies a contract that inheritors or implementers must adhere to. Abstract types have the option of providing implementation details; interfaces cannot provide any implementation details.
Do not provide abstractions unless they are tested by developing several concrete implementations and APIs that consume the abstractions.
If you ship abstractions without testing them in real-world scenarios, you will most likely miss design issues that are difficult or impossible to fix without introducing compatibility issues in future releases.
Do choose carefully between an abstract class and an interface when designing an abstraction.
For a detailed discussion about selecting an abstract type or interface, see Choosing Between Classes and Interfaces.
Consider providing reference tests for concrete implementations of abstractions. Such tests should allow users to test whether their implementations correctly implement the contract.
Reference tests are tests that allow you to verify that you have implemented an interface correctly. For example, a test for ICollection can verify that after calling the Add method twice on an instance implementing the interface, the Count property increases by two.
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
Other Resources
Design Guidelines for Developing Class Libraries
Designing for Extensibility