Newbie trying to grok namespaces

[carl.manaster]

Hi,

I'm trying to get a feel for how to organize namespaces. I've used
languages, C++ and others, that had them before, but they've never been
so conspicuous as they seem to be in C# - appearing at the start of
every file as they do. I could just go with one namespace for all the
code I write, but I realized I was writing namespace-like features into
my names and thought - aha! maybe that's how I should be using
namespaces.

My application has a variety of different floating utility windows,
each with special geometry and rules for dragging (like resize
behavior), and I've written classes to handle all the dragging. Take
the two utility windows Magnifier and Filter as examples. I've got
some parallel and near-parallel class hierarchies going:

System.Windows.Form <object>
|-MyApp.FlexibleForm <object> |-Dragger
|-MagnifierForm |-MagnifierGeometry |-Mag...
|-FilterForm |-FilterGeometry |-Fil...

[hoping that all comes out nicely unmangled...]

And, in fact, when I originally wrote MagnifierGeometry, I just put
"Geometry" as the classname, into the "Magnifier" namespace. When I
got around to working on Filters, I got to thinking that I could even
name FilterForm just "Form", FilterDragger as "Dragger", etc., all
keeping within the "Filter" namespace. So this would look more like:

System.Windows.Form
|-MyApp.FlexibleForm <object>
|-Magnifier.Form |-Magnifier.Geometry
|-Filter.Form |-Filter.Geometry

and the code would be narrower within each namespace, where I could
leave off the namespace prefixes (Filter.Form simply refers to
Geometry, for example, instead of FilterGeometry).

Also I could nest these new namespaces into MyApp's namespace, or leave
them outside it. I could create a FlexibleForm namespace for the base
of my forms, a Geometry namespace for the base of my Geometries (if I
had one), a Dragger namespace for the base of my Draggers, etc. - but I
don't see too much advantage in that.

Sooooo... Am I going namespace-crazy? I think I "get" the mechanics
of namespaces, what's allowed and possible, but I don't yet have a
sense of what constitutes a good use of them. Or how to make good
decisions about them. My inclination at the moment (beyond asking
y'all) is to have namespaces for the different kinds of utility windows
and simplify the classnames within them, but not to nest these
namespaces within MyApp, and not to add namespaces for the root
classes. I look forward to the discussion...

Peace,
--Carl

 

[Chris R. Timmons]

Carl,

Namespaces share a property of classes in that both constructs
provide for logical encapsulation of code. MS provides some
guidelines here:

http://msdn.microsoft.com/library/d...enref/html/cpconNamespaceNamingGuidelines.asp

Personally, I use namespaces to encapsulate broad areas of my
applications, and use classes to encapsulate the details. For
example, when building a three tier application I typically
have three namespaces: UserInterface, BusinessLogic, and DataLayer.

My reasoning behind this is to simplify the overall architecture
of my apps. It can be difficult enough navigating a large class
hierarchy. Adding a complex namespace hierarchy on top of that
can needlessly complicate the architecture.

Another criteria I use in deciding on a namespace hierarchy is to
plan for the future of my code base. To paraphrase General
Douglas MacArthur, "Old code never dies, it just gets maintained."
If the namespaces become too detailed ("rigid"), or deeply nested,
then it may be a very expensive proposition to add new classes or
modify existing class hierarchies later on.

That said, nested namespaces do have their place. The .Net
framework library is a good example of a well designed namespace hierarchy.
There are several large open source C# apps you can look at to get
an idea of how namespaces are used (both well and poorly).

http://csharp-source.net/
http://sourceforge.net/projects/prevayler/
http://www.rssbandit.org/
http://www.icsharpcode.net/OpenSource/SD/Default.aspx