通过

Framework Design Guidelines: An appeal for consistency

  • 项目

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.

Comments

  • Anonymous
    December 15, 2008
    PingBack from http://blog.a-foton.ru/index.php/2008/12/16/framework-design-guidelines-an-appeal-for-consistency/

  • Anonymous
    December 16, 2008
    The comment has been removed

  • Anonymous
    December 16, 2008
    Static methods follow the same convention as anything else for naming :)

  • Anonymous
    December 16, 2008
    @Shail Naming convention should indeed be the same, I think. In your example, however, in combination with patterns and practices, it might be more appropriate to have a static "ProductRepository" class for the logical CRUD-related functions, that typically uses instances of the non-static "Product" class. That would better separate the concerns, having functions such as "Add" etc. placed on a 'collection'-oriented repository.

  • Anonymous
    December 19, 2008
    It's funny. My advice is the total opposite. If you have a interface -> class pair that only differ on the "I" prefix on the interface name, you should maybe reconsider your naming. Let me mention the IList -> List naming as one of my favourite naming disasters. Why is the ArrayList the default implementation? Will MS change the behaviour of List in future releases? IList -> ArrayList is much more clear. Generally I don't like DO and AVOID style of the book as framework design to me isn't something that can be by having a set of design rules. http://dotnetexception.blogspot.com/2006/11/promoting-interfaces.html

  • Anonymous
    December 23, 2008
    Rune Juhl-Petersen, no offense but you are missing that List(Of T) is a default implementation of IList(Of T). With IList it's more complicated, because ArrayList() was built around Array and named this way because of an Array. Although what it is is a list, so behind it has a IList interface. How would you handle a classic IShape where you don't work with shape rather you work with rectangles, triangles, circles, etc implementing IShape??

  • Anonymous
    December 28, 2008
    You are right Alex, I'm reffering to the generic version of the Collection framework. List<T> is, as ArrayList, build around an array. It is stated so in the documentation. My problem with it is that without the msdn documentation there is no way the programmer can make a sensible choice between the List<T> and the LinkedList<T>. There is no way you can tell what benefit you get by choosing List<T> over LinkedList<T>. The nongeneric version of the collection framework is much more clear, because here you can actually see what is happening just by looking at the code. With your IShape example I would handle it by not having a Shape class at all. There is no need for it from a architectural view. You might need an abstract class to implement som common functionality, but I would recommend that you do not call it "Shape". The name "Shape" is a completely abstract concern, and unless your "Shape" is purely abstract (contains no implementation) I would not recomend naming it "Shape". Instead I would recommend that you give it some name that indicates what it brings to the party. A good framework exposes all information that could be relevant for the programmer and if possible does so directly through its structure and naming. These are ofcourse just my personal fealings, and generally I just have one rule of architecture and framework design. It depends!!! There is no DO and no AVOID. Consider the situation and act on it. Parden my english. Its not my primary language!