C# Tutorial - Dissecting Our First Application - Namespaces

A namespace can be seen as a container for some classes in much the same way that a folder on your file system contains files. All of the classes that come with the .NET Framework can be accessed through their namespaces by the using keyword.

In this example, the using System; declaration, tells the program that it can reference the code in the System namespace without adding the word System to every place a reference would need it. If we did not have the using System; declaration, the program statement Console.WriteLine( "Hello World!" ); would look like the following:

System.Console.WriteLine( "Hello World!" );

The namespaces that are declared in the .NET Framework, such as System, contain pre-written code that is known as the .NET Framework Class Library.

In a similar fashion, we can create our own namespaces to hold any objects that we create. The IDE has defaulted the name of our namespace to _4_HelloWorld, so that it is different to all of the namespaces used within the .NET Framework.

Every declared namespace must be enclosed in curly braces ({}). Thus the line after the namespace declaration is an open brace to mark the beginning of the scope of the namespace. The open brace is matched by a closing brace at the end of the scope of the namespace.

Examples of namespaces in the .NET Framework Class Library

The System.Drawing namespace provides access to a number of drawing tools. For example, the namespace classes include Brush, Cursor, Font, Pen and so on. The namespace structures include Color, Point, and Rectangle. The namespace enumerations include BrushStyle and PenStyle.

The System.Windows.Forms namespace provides class support for a variety of forms and controls. For example, classes are provided for Border, Button, CheckBox, CommonDialog, Form and ListBox. This class support spans dialog boxes, forms and controls. Delegate support is provided for both forms and controls. Enumerations include enumerations for styles and states for forms and controls.

Namespaces and Classes

By putting the classes into namespaces we can group related classes together. If two classes have the same name, by placing them in different namespaces, we avoid the risk of name collisions.

Namespaces promote re-usability, by partitioning code so that identifiers don't conflict: A general recommendation is to use your company and project names as part of the namespace, since that helps make them unique. If everyone just used demo as a namespace name, then there would be many more conflicts. But by using Publicjoe.Windows.Demo, you make it less likely that someone else will pick that particular namespace name.

Also, when I am writing even a simple program, it isn't unusual for me to build some utility classes. I will tend to think ahead of time about whether each utility class has value in the future in other programs - if it does, I will put it in a different namespace, and try to keep dependencies separate from the rest of the program. Then I have a better chance of being able to re-use it without changes in a later program.

The true name of any given class consists of the fully qualified class name, for example:

namespace foo
{
  class bar{}
}

In this case the name of the class is foo.bar. If you call this from client code that has a using foo; directive at the top, you would not have to actually spell it out completely - but that is still its full name.

If you declare a class named bar in two different assemblies, and tried to reference them within the same app, there would be a conflict unless different namespaces had been used. If you used the namespace boo in one of the projects, then you could differentiate between them by specifying foo.bar or boo.bar.

There is nothing necessarily wrong with using the same namespace in two different projects (it may even be desirable) but it depends on the circumstances.

Here is an example: Imagine you are Publicjoe Consulting and you have a client called Hard-Men Money Lenders. You write an application called Money Manager, so you could use the namespace Publicjoe.HardMen.MoneyManager. You could organize it like this:

• Publicjoe - general-purpose utility code that might be used anywhere, for any client.

• Publicjoe.HardMen - code that might be used in multiple applications for Hard-Men client.

• Publicjoe.HardMen.MoneyManager - code specific to this application.

Eventually you might well have multiple projects that use any of these namespaces, but you would put the appropriate code in the appropriate namespace. Likely, over time you would develop an application framework and would use some of the same class names in multiple applications, but since each app lives in its own namespace there would be no naming conflicts.