.Net Framework Design Guidelines

Designing For Extensibility

ConsiderUnsealed classes with no added virtual or protected members as a great way to provide inexpensive yet much appreciated extensibility to a framework.
ConsiderUsing protected members for advanced customization.
DoTreat protected members on unsealed classes as public for the purpose of security, documentation, and compatibility analysis.
ConsiderUsing callbacks to allow users to provide custom code to be executed by the framework.
ConsiderUsing events to allow users to customize the behavior of a framework without the need for understanding object-oriented design.
DoPrefer events over plain callbacks as they are more familiar to a broader range of developers and are integrated with Visual Studio.
AvoidUsing callbacks in performance-sensitive APIs.
DoUnderstand that by calling a delegate, you are executing arbitrary code and that could have security, correctness, and compatibility repercussions.
Do NotMake members virtual unless you have a good reason to do so and you are aware of all the costs related to designing, testing, and maintaining virtual members.
ConsiderLimiting extensibility to only that absolutely necessary through the use of the Template Method Pattern.
Do NotProvide abstractions unless they are tested by developing several concrete implementations and APIs consuming the abstractions.
DoChoose carefully between an abstract class and an interface when designing an abstraction.
ConsiderProviding reference tests for concrete implementations of abstractions.
ConsiderMaking base classes abstract even if they don't contain any abstract members.
ConsiderPlacing base classes in a separate namespace from the mainline scenario types.
AvoidNaming base classes with a “Base” suffix if the class is intended for use in public APIs.
Do NotSeal classes without having a good reason to do so.
Do NotDeclare protected or virtual members on sealed types.
ConsiderSealing members that you override.