Share via

Measuring Namespace Complexity

  • Article

One of the nice things about the .NET Framework (particularly vs. Win32) was its discoverability. There were 108 namespaces and about 3,800 types. There were just a few top-level namespaces and really only a few you needed to think about (System.Web, System.Windows, System.Data, etc.). As we move forward toward the Whidbey release and the WinFX/Longhorn release, we're adding functionality and consequently adding types -- Whidbey may have something like 7,000 types. So how do we balance functionality and namespaces? How many top-level and second-level namespaces should we have? How many members per type? How many types per namespace?

Comments

  • Anonymous
    January 14, 2004
    I think those are unquantifiable questions. It shouldn't be a matter of how many goes in where, etc. It should be a matter of the API being intuitive and making sense. I'm hardly an expert on API design, but the point should be intuitivity (sp?) and ease of use. How do I get what I need as quickly as possible (i.e. the "My" classes in VB.NET 8.0)

    I'd rather see an elimation of redundancy as being a primary objective than trying to reorder the API to retain a balanced headcount. There are tons of places where the same result could be accomplished 6 different ways (the Style classes are definitely one of those), and I think it would behoove MS to phase out the ones that are less performant / poor choices in practice, as a way of forcing programmers to write better code.
  • Anonymous
    January 14, 2004
    I find tools like Lutz Roeder's Reflector help a great deal when it comes to discoverability, especially the Type and Member searches.
  • Anonymous
    January 14, 2004
    namespaces do an excellent job of making it intuitive to find what you're looking for.

    in "menu theory" there's a rough rule to limit things to around seven items. ie - up to seven main menu items, with up to seven items in each one, and so on...

    you can push it just a little further than this - but not a lot more.

    if you have, say 10 classes, 10 interfaces, 10 enums and 10 inner namespaces within each namespace - then this gives you a nice compromise between size and searchability. any more than that and you are starting to push it.

    but like george orwell says (and I'm paraphrasing here) "break any of these rules sooner than write an unusable API"

  • Anonymous
    January 14, 2004

    Robert pretty much said it. Rather than focusing on numbers, it's more important to focus on discoverability. This would argue for having the namespace hierarchy match the way you teach people about the technology. So, I'd have a System.Indigo namespace to contain all of Indigo. Refer to the PDC Indigo architecture slide at
    http://microsoft.sitestream.com/PDC2003/WSV/WSV201_files/Botto_files/323,12,Indigo Architecture. I would make System.Indigo.ServiceModel, System.Indigo.Connector, System.Indigo.MessagingServices and System.Indigo.SystemServices be the 4 child namespaces. Under Connector, you would have System.Indigo.Connector.Channels and so on.

    KC
  • Anonymous
    January 18, 2004
    This post has gotten a lot of feedback. In an internal email thread on this posting, Michael Murry on the .NET team pointed out "that namespaces represent an index into functionality for developers. I liked the post about 'menu theory' although I think the # of types below a namespace is less important for recall than keeping the # of top-level namespaces relatively small."
  • Anonymous
    January 18, 2004
    The comment has been removed
  • Anonymous
    January 19, 2004
    The comment has been removed
  • Anonymous
    January 19, 2004
    The comment has been removed
  • Anonymous
    January 19, 2004
    So you didn't rebuild the proxy -- you just changed the URI it pointed to?
  • Anonymous
    January 19, 2004
    I have webreferences, and build with one at a time:

    'friend ws as new Live.wsLive
    friend ws as new Dev.wsDev

    ws.someMethod()

    if someMethod returns a typed dataset, the types are different from dev or live, even if I've given them the same namespace.

    Here's an MSDN article about this:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service07162002.asp
  • Anonymous
    January 19, 2004
    I can't believe how complicated you people are making this.

    Design the API around the abstractions and the logical connections and organisation of those abstractions.

    It's that sort of thing that gets you your discoverability.

    Namespace usage is just an artefact of that sort of sensible design.
  • Anonymous
    January 24, 2004
    yup
  • Anonymous
    January 24, 2004
    ?
  • Anonymous
    March 18, 2004
    I can only agree with Joseph. Reflector and people that actually know what they are doing are the two ingredients for good API design. The process of designing an API can't be covered by scientific metrics.
  • Anonymous
    March 25, 2004
    The comment has been removed
  • Anonymous
    June 21, 2004
    Scientific metrics dont really come in play to the full extent when dealing with API design, you have to think more about process.
    neteller online casinos
  • Anonymous
    June 21, 2004
    The comment has been removed
  • Anonymous
    June 22, 2004
    I agree
  • Anonymous
    July 10, 2004
    nice http://www.gifs-bilder-banner.breseinfo.de/
    http://www.songtexte.breseinfo.de/
    http://www.vornamen.breseinfo.de/