Framework Design Guidelines: An appeal for consistency

  • Article

Continuing in our weekly blog post series that highlights a few of the new image5_thumb2_thumb2_thumb_thumb_thu_thumbadditions to the Framework Design Guidelines 2nd edition.. This content is found in the Names of Classes, Structs, and Interfaces section of Chapter 3: Naming Guidelines. Even in the .NET Framework we don’t always apply the design guidelines consistently – and, as Phil found out, we often pay the price for it.

DO ensure that the names differ only by the “I” prefix on the interface name when you are defining a class–interface pair where the class is a standard implementation of the interface.

The following example illustrates this guideline for the interface IComponent and its standard implementation, the class Component:

public interface IComponent { … }

public class Component : IComponent { … }

PHIL HAACK

One place where the framework violates this convention is the class HttpSessionState, which you would suspect implements IHttpSessionState, but you’d be wrong, as I was.

This inconsistency nearly bit us when we were developing our HttpContextBase abstraction of HttpContext, because it seemed we could expose the Session property as the IHttpSessionState interface, which turned out to not be the case.