Measuring Namespace Complexity


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 (19)

  1. 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.

  2. JosephCooney says:

    I find tools like Lutz Roeder’s Reflector help a great deal when it comes to discoverability, especially the Type and Member searches.

  3. 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"

  4. Ken Cowan says:

    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

  5. 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."

  6. Dennis says:

    I’ll be happy if you trust *my* namespaces for webservices. If I have two different webservices, and I’ve given them the same namespace, then objects defined there should be considered the same type by my client code.

    Example: I made a typed dataset for use in a clientside crystal report. I tested on my dev webservice. Repointed to live, same namespace, same definition, and find it’s a different type, not convertible, because .net adds a little extra to my namespace based on which webreference I’m using.

    I’ve found workarounds, but they’re cumbersome and annoying. If I say they’re the same namespace, just trust me. If I then screw it up, I’ll have no one to blame but myself.

  7. There’s a balance between what you describe (which leads to DLL hell) and what the .NET Framework does today (which leads to very cumbersome overriding). Folks like Jim Miller and Jeff Richter are actively working on how to get a better balance in an upcoming version.

  8. Dennis says:

    The difference between this and DLLs is that in a webservice situation, you usually have at least a dev and production webservice. With DLLs you can test the new "live" version on a local box. It’s a different ballgame when the "dll" is on just one server, which is being used by customers. In that situation, I can’t mess with it until I’ve validated the new code somewhere else, and that makes it a royal pain when the "somewhere else" is forcibly turned into a different namespace. Since both the servername and the asmx name are mungled into the namespace, there’s no setup that will avoid the problem.

    Glad to hear somebody’s working on it, though.

  9. So you didn’t rebuild the proxy — you just changed the URI it pointed to?

  10. Dennis says:

    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

  11. Iain says:

    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.

  12. Anonymous says:

    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.

  13. all this is actually a bit too complex. what a muscle-head

  14. 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

  15. measuring datasets within namspace is quite trivial. there are several good reviews of online casinos, with high payouts.